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FOREWORD 


This  Is  the  final  report  for  Phase  II  of  the  Scheduling  Language  and 
Algorithm  Development  Study  (NAS9-13616) . It  is  contained  in  three 
volumes.  The  objectives  of  Phase  II  V7ere  to  implement  prototypes  of 
the  Scheduling  Language  called  PLANS  and  the  scheduling  module  library 
that  were  designed  and.  specified  in  Phase  I. 

Volume  I,  of  this  report  contains  data  and  analyses  related  to  a 
variety  of  algorithms  for  solving  typical  large-scale  scheduling  and 
resource  allocation  problems.  The  capabilities  and  deficiencies  of 
various  alternative  problem  solving  strategies  are  discussed  from  the 
viewpoint  of  computer  system  design. 

Volume  II  is  an  introduction  to  the  use  of  the  Programming  Language 
for  Allocation  and  Network  Scheduling  (PLANS) . It  is  intended  as  a 
reference  for  the  PLANS  programmer. 

Volume  III  contains  the  detailed  specifications  of  the  scheduling 
module  library  as  implemented  in  Phase  II.  This  volume  extends  the 
Detailed  Design  Specifications  previously  published  in  the  Phase  II 
Interim  report  (April  1975). 
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INTRODUCTION 


During  Phase  i of  the  Scheduling  Language  and  Algorithm  Develop- 
ment Study,  a computer  programming  language  and' a library  of  modules 
(subroutines)  were  designed  and  functionally  specified.  These 
functional  specifications  appear  in  Volume  III  of  the  Phase  I Final 
Report.  The  interested  reader  can  also  refer  to  Volumes  I and  II  of 
the  Phase  I Final  Report  which  provide  overview  and  usage  information. 
The  information  in  this  introduction  is  intended  to  provide  a brief 
background  and  a context  for  the  detailed  design  specifications 
which  follow  in  subsequent  sections. 

The  products  of  this  study  are  called  PLANS  (Programming 
Language  for  Allocation  and  Network  Scheduling)  and  the  PLANS 
Module  Library.  These  products  are  designed  to  reduce  substan- 
tially the  costs  and  span  times  of  implementing  software  to  solve 
scheduling  and  resource  allocation  problems . Most  programs  assoc- 
iated with  planning  and/or  managing  the  activities  and  resources 
in  a large  operational’  system  are  programs  that  should  be  imple- 
mented using  the  products  of  this  study. 

It  should  be  understood  that  this  study  does  not  develop 
complete  scheduling  system  application  programs  or  a language  in 
which  a'  user  communicates  with  a scheduling  system.  PLANS  users 
are  assumed  to  be  charged  with  the  design  or  modification  of 
application  programs  related  to  scheduling  and  resource  assignment 
(allocation),  that  could  be  part  of  a scheduling  system.  Also, 
potential  users  are  assumed  to  have  a problem  orientation  (as 
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opposed  to  computer  programming  orientation)  that  is  not  limited  to 
aerospace  system  applications.  Thus,  a language  and  associated  basic 
data  structure  and  routines  are  being  developed  to  provide  high- 
level  but  flexible  programming  capability  to  analysts  with  a wide 
variety  of  scheduling  and  resource  allocation  problems. 

The  Phase  I study  showed  that  increasing  correspondence  between 
the  individual  logical  operations  of  the  problem  solution  and  the 
individual  computer  program  statements,  greatly  increased  the  in- 
herent usability  of  the  language  for  the  user  concerned  with  schedul- 
ing/resource allocation  problems.  However,  practical  limits  to  doing 
this  in  the  basic  language  must  be  recognised,  because  too  much 
individual  statement  power  would  unnecessarily  reduce  the  flex- 
ibility of  the  language. 

To  provide  functions  that  have  more  power  than  available  from 
individual  PLANS  statements,  the  Phase  I study  specified  a flexible 
data  structure  especially  suited  for  describing  operating  systems, 
and  a library  of  subroutines  called  modules  for  use  with  the  struc- 
ture and  PLANS  (the  scheduling  language) . This  combination  of  a 
flexible  language  and  data  structure,  plus  a library  of  prepro- 
grammed modules  constitutes  a software  programming  system.  The 
PLANS  Programming  System  consists  of  three  elements  which  together 
simplify  the  development  or  modification  of  scheduling/resource 
allocation  software. 

In  summary,  these  products  are: 

1)  A high-level  progranming  language  for  writing  scheduling  programs 

that 


2 


- Use  typical  arithmetic,  transfer-of-control,  conditional 
and  iterative  statements  in  logic  and  computational  modules, 

- access  and  manipulate  the  data  structure  for  problem/module 
support , 

- define  the  problem/objectives  and  manipulate  the  library 
modules ; 

2)  A flexible  data  structure  specially  suited  for  describing  the 

characteristics  of  the  systems  to  be  scheduled; 

3)  A library  of  preprogrammed  logic  modules  to 

- access  the  data  structure  for  system  operations  data, 
implement  frequently  used  scheduling/resource  allocation 
problem  solution  algorithms. 

This  programming  system  meets  the  prime  requirements  for  (1) 
substantially  reducing  software  programming  and  reprogramming  times, 
(2)  desensitizing  programs  to  problem  changes,  and  (3)  accommodat- 
ing a wide  range  of  problem  types  and  applications  with  generic 
logic  codes. 
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.0  DETAILED  DESIGN  SPECIFICATION  FOR  PLANS  PROGRAMMING  LANGUAGE 

PLANS  has’  been  implemented  by  a two-pass  translator.  The  first 
pass  performs  a syntax  check  with  appropriate  error  messaging  and 
recovery.  The  second  pass  translates  PLANS  to  PL/^I.  Both  of  these 
programs  were  developed  using  the  Martin  Marietta  Aerospace  Trans- 
lator-Writing System  (TWS) . TWS  is  a system  in  which  translators 
are  automatically  generated  from  an  appropriate  formal  definition, 
in  the  form  of  an  "augmented  grammar",  of  the  translation  process. 
Since  the  augmented  grammar  definitions  of  the  PLANS  Syntax  Checker 
and  the  PLANS  Code  Generator  are  more  complete  and  rigorous  than 
those  achievable  by  most  other  means,  they  provide  an  excellent 
means  of  functional  definition.  Before  they  can  be  understood,  how- 
ever, it  will  be  necessary  for  the  reader  to  familiarize  himself 
with  TWS.  A functional  description  of  TWS  is  included  in  this  docu- 
ment as  Appendix  1.  It  is  suggested  that  the  Appendix  be  consulted 
before  proceeding, 

1.1  PLANS  Lexical  Analyzer 

The  state  transition  diagram  for  the  PLANS  lexical  analyzer  is 
shown  in  Fig.  1.1-1.  This  lexical  analyzer  is  used  in  both  the 
syntax  checker  and  the  code  generator.  Notice  that  comments  are 
removed  by  the  lexical  analyzer,  .and  need  not  be  considered  in  the 
augmented  grammars. 

1.2  Specialized  PLANS  Output  Routine 

The  output  routine  (aoUT  was  changed  for  the  PLANS  code  generator 

to  allow  the  user  to  insert  code  prior  to  the  current  line  of  code 
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' in  the  code  buffer.  This  allows  the  user  to  start  outputting  a line 

of  data  and  at  any  point,  output  any  number  of  lines  prior  to  the 
current  line  by  incrementing  a grammar  switch  called  NORMA.L__MERGE__ 
SWITCH.  For  example, the  user  can  output  a segment  of'' line  A,  then 
decide  a line  B is  needed  prior  to  A.  If  while  outputting  line  B 
the  need  for  a line  C before  line  B is  needed  the  new  line  C can  be 
output,  then  more  added  to  B and  output,  as  well  as  more  added  to  A. 
This  procedure  can  be  nested  to  any  arbitrary  depth  by  incrementing 
and  the  decrementing  N0RMAL_JIERGE^SWITCH,  which  corresponds  to  the 
current  nesting  level. 

1.3  PLANS  Syntax  Checker 

The  error  message  declaration  for  the  syntax  checker  is  shown 
in  Fig.  1.3-1.  Fig.  1.3-2  contains  the  complete  augmented  grammar 
for  the  S3mtax  checker.  It  is  suggested  that  this  grammar  be  studied 
before  that  of  the  code  generator,  which  is  somewhat  more  complex. 

1.4  PLANS  Code  Generator 

The  error  message  declaration  for  the  code  generator  is  shown 
in  Fig.  1.4-1.  Fig.  1,4-2  contains  the  augmented  grammar  for  the 
PLANS-J*PL/I  translation  pass. 

1.5  Comparison  of  Implementation  with  Original  Functional  Specification 

With  minor  exceptions,  all  the  functional  capabilities  outlined 
in  the  PLANS  language  specification  (Phase  I Final  Report,  Vol  III, 
September,  1974)  have  been  provided  in  the  implemented  translator. 

In  addition,  numerous  capabilities  which  were  not  specified  have 
been  provided.  This  section  lists  the  deviations  from  the  specif i- 
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/*  ERROR  MESSAGES-  */ 

DECLARE  aERR0R_MESSAGE(92)  CHARACTER(60)  VARYING  STATIC  INIT( 


SiHAIN  PROCEDURE  NAME  HISSING*.  /*01*/ 
SiMISSING  PROCEDURE  STATEMENT* , /*02*/ 
SrINTERNAL  PROCEDURE  NAME  MISSING*.  /*03*/ 
WiHISSING  LEFT  PARENTHESIS  ASSUMED  PRESENT*.  /*0^*/ 
S:MISSING  or  ILLEGAL  MAIN  PROCEDURE  OPTION  LIST*.  /♦05*/ 
S:HISSING  or  ILLEGAL  PROCEDURE  PARAMETER  LIST*.  /*06*/ 
S:MISSING  MAIN  PROCEDURE  END-STATEMENT’ , /*07*/ 
S:STATEMENTS  AFTER  END-STATEMENT* , /»08*/ 
S:UNRECOGNIZABLE  STATEMENT*.  /♦OP*/ 
S:MISSING  INTERNAL  PROCEDURE  END-STATEMENT* , /*10*/ 
NtNDNITERATIVE  DO-GROUP  EXECUTES  MORE  EFFICIENTLY  HERE*.  /*11*/ 
StMISSING  BEGIN-BLOCK  END-STATEMENT*.  /*12*/ 
SiMISSING  OR  ILLEGAL  BOOLEAN  EXPRESSION*.  /*13*/ 
WtTRACE  IGNORED  — TRACE  OPTION  NOT  SELECTED*,  /*14*/ 
S:TRACE  LEVEL  NOT  SPECIFIED’ , /*15*/ 
S:’’*NULL"  CANNOT  BE  MODIFIED  OR  PASSED  AS  PARAMETER*,  /*16*/ 
SJMISSING  word  "BEFOREr’  /*17*/ 
STMISSING  WORD  "AT’”.  /♦IB*/ 
SsUNINTER PRETABLE  ITERATION  CLAUSE  IN  DO-STATEMENT*.  /*19*/ 
W:HISSING  WORD  ’*OF"  ASSUMED  PRESENT* , /*20*/ 
STMISSING  OP  ERRONEOUS  TREE  NODE  EXPRESSION’ , /*2I*/ 
HSMISSING  WORD  "USING"  ASSUMED  PRESENT*,  /*22*/ 
SiMISSING'OR  ERRONEOUS  TREE  NAME*,  /*23*/ 
WrMISSING  WORD  "ALL"  ASSUMED  PRESENT*,  /*24*/ 
N:LABEL  ignored — PLANS  DOES  NOT  ALLOW  MULTIPLE  CLOSURE*,  /*25*/ 
SiUNEXPECTED  END  OF  FILE  ENCOUNTERED*.  /*2j&*/ 
WsMlSSING  DECLARATION  LIST*,  /*27*/ 
SJEXTRANECUS  INFORMATION  IN  BOOLEAN  EXPRESSION*,  /*28*/ 
WsSEMI-COLON  AFTER  IF-CLAUSE  IGNORED*,  /*29*/ 
S:THEN-CLAUSE  REQUIRES  EXECUTABLE  STATEMENT  OR  BLOCK*,  /*30*/ 
S;ELSE-CLAUSE  REQUIRES  EXECUTABLE  STATEMENT  OR  BLOCK*.  /*31*/ 
SrMISSING  THEN-CLAUSE  IN  IF-STATEMENT* , /*32*/ 
WtMISSING  WORD  "AS"  ASSUMED  PRESENT*,  /*33*/ 
S:ILLEGAL  multiple  NODE  REFERENCE*,  /*34*/ 
StELSE-CLAUSE  NOT  ASSOCIATED  WITH  IF-STATEMENT*,  /*35*/ 
SiDECLARATIONS  ALLOWED  ONLY  AT  START  OF  BLOCK*,  /*36*/ 
SsHISSING  DO-GROUP  END-STATEMENT*,  /*37*/ 
S:MISSING  WORD  "TAKEN"*,  /*38*/ 
SlMISSING  OR  ERRONEOUS  ARITHMETIC  EXPRESSION*,  /*39*/ 
W:MISSING  WORD  "A"  ASSUMED  PRESENT*,  /*40*/ 
WtMISSING  WORD  "TIME"  ASSUMED  PRESENT*,  /*41*/ 
WtMISSING  WORD  "TO"  ASSUMED  PRESENT*.  /*42*/ 
StMISSING  OR  ERRONEOUS  LABEL  REFERENCE*,  /*43*/ 
StMISSING  OR  ERRONEOUS  PROCEDURE  REFERENCE*,  /*44*/ 
StMISSING  OR  ERRONEOUS  CALL  ARGUMENT’,  /*A5*/ 
StEXTRA  ARITHMETIC  OPERATOR*,  /*46*/ 
StMISSING  OR  ILLEGAL  OPERAND  IN  ARITHMETIC  EXPRESSION’,  /*47*/ 
StMISSING  OR  ERRONEOUS  »NUMBEP"-FUNCTION  ARGUMENT*,  /♦48^/ 
StMISSING  OR  ILLEGAL  TREE  LABEL*,  /♦AP^/ 
Nt"NEXT"  IS  USED  AS  LABEL,  NOT  SUBSCRIPT  KEYWORD*,  /*50^/ 
St"NEXT"  ILLEGAL  HERE*,  /♦51^/ 
Nt"LAST"  IS  USED  AS  LABEL,  NOT  SUBSCRIPT  KEYWORD*,  /*5Z*/ 
Sf'ALL"  ILLEGAL  HERE*,  /*53*/ 
St’’LABEL"-FUNCTION  CANNOT  BE  USED  AS  DIRECT  TREE  LABEL*,  /♦SA*/ 
StINDIRECT  REFERENCE  ILLEGAL  HERE*,  /♦55^/ 
StMISSING  OR  ERRONEOUS  "LABEL"-FUNCTION  ARGUMENT*.  /*56*/ 


\ 
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*StMISSING  OR  ERRONEOUS  STRING  EXPRESSION’,  /"ST*/ 
’StSUBSCRIPT  KEYWORD  "FIRST"  NOT  ALLOWED  AS  LABEL’,  /*5Q*/ 
’WtEXTRA  COMMA  IGNORED',  /♦SP*/ 
•WtMISSING  COMMA  ASSUMED  PRESENT’,  /*60*/ 
’StMISSING  OR  UNINTERPRETABLE  ELEMENT  IN  PROPERTY  LIST*,  /♦61*/ 
•StMISSING  OR  ILLEGAL  INDIRECT  TREE  NODE  REFERENCE*.  /♦62^/ 
•StMISSING  OR  ERRONEOUS  INPUT/OUTPUT  LIST*. 

’StMISSING  RIGHT  PARENTHESIS*. 

’StEXTRANEOUS  OR  UNINTERPRETABLE  INFORMATION*,  /*bS*/ 
’StMISSING  OR  ILLEGAL  TREE  OR  VARIABLE  NAME*.  /*bb*/ 
’StNUHBER  OF  NODES  INCORRECTLY  SPECIFIED*.  /*bl*/ 
’StNUMBER  OF  LABELS  INCORRECTLY  SPECIFIED • , /♦68^/ 
’NtPOSSIBLE  ATTEMPT  TO  INSERT  BEFORE  ROOT  NODE*,  /*b<)*/ 
’St"ALL"  NOT  ALLOWED  AS  LABEL  QUALIFIER*.  /*70*/ 
’StMISSING  OR  ERRONEOUS  BOOLEAN  RELATION*,  /*71"/ 
’StMISSING  INPUT  OR  OUTPUT  FILE  NAME*, 

’StNEGATED  BOOLEAN  EXPRESSION  MUST  EE  IN  PARENTHESES’,  /*73*/ 
*St’’$COMBINATION"  OR  "JPERMUTATIDN"  REQUIRES  SUBSCRIPT’ , /♦TA^/ 
’StARITHMETIC  EXPRESSION  IS  REQUIRED  HERE*.  /*75*/ 
’StREMOVAL  OF  iCOMBlNATION  OR  IPERMUTATION  SUBNOOE  ILLEGAL • ,/*76^/ 
’StCOMBINATION  AND  PERMUTATION  LOOPS  MAY  NOT  BE  NESTED*,  /*77*/ 
’WtCALL  ARGUMENT  MAY  RESULT  IN  TYPE  ERROR’,  /♦78^/; 
’StPROCEDURE  HAS  CONFLICTING  MAIN  AND  EXTERNAL  OPTIONS’,  /*79*/ 
’StNODES  OPTION  NOT  ALLOWED  IN  EXTERNAL  PROCEDURE*,  /♦80^/ 
’StPARAMETER  LIST  NOT  ALLOWED  IN  MAIN  PROCEDURE*,  /♦81"/ 
’StRECURSIVE  FEATURE  NOT  ALLOWED  IN  MAIN  PROCEDURE*,  /*BZ*/ 
’WtMISSING  ATTRIBUTE  "LOCAL"  ASSUMED  PRESENT*,  /♦83^/ 
•StMISSING  PROPERTY  LIST*,  /♦84^/ 
•StINDIRECT  REFERENCE  IS  A LABEL, NOT  SUBSCRIPT, QUALIFIER  * , /*85*/ 
•StMISSING  LEFT  PAREN  ON  LABEL  FUNCTION  ARGUMENT*,  /♦86^/ 
*St"GRAFT  *TREE{ALLt  )"  NOT  PRESENTLY  IMPLEMENTED*,  /•B7*/ 


*St"(GRAFT)  INSERT  STREEfALLt  )’>  NOT  PRESENTLY  IMPLEMENTED*, 
*St"ALL"  CAN  BE  USED  ONLY  FOR  CONDITIONAL  ACCESS  ("ALLt")*,  /*B9*/ 


*St"FIRSTl"  IS  SUBSCRIPT,  NOT  LABEL.  QUALIFIER*,  /♦90*/ 
*St"ALLt"  IS  SUBSCRIPT,  NOT  LABEL,  QUALIFIER*,  /♦91^/ 
’StMISSING  OR  ERRONEOUS  EXPRESSION’ » ; /*9Z*/ 


.OPTIOBJLIST  (PDHCH  CODP  = TES,  PRI»T_CODE  = »0) 

.SnG_GRlH  PLBSm  ^(.IHIII1L_C0DE  = SISDCL,  .PINAl_CODP  = STHHEP) 


/»*♦♦♦♦♦******•***♦***♦♦♦••♦/ 

/»  BJISIC  PSOGEIE  STRDCTORE  */ 


PLISTB  ;= 

/*  .SET|ALLSnCH  PXAG  = 0)  */ 

/•  .SETilRITR  OPER»TIOH_F1»G  = 0)  V 

/*  .SET  (COBB  OR_PERE_l.OOP_FI.iG  = 0)  V 

/*  .SET(E»D_OT_FILE_FtiG  = 0)  ♦/ 

/*  .SET(L1BF1  FLiG  = 0)  */ 

/*  .SET(Hil«_ErrFRSll_«EITRFH_SBITCH  = 3)  •/ 

/*  .SET  |■ODES_PiH»B_lEITEER_SBITCB  = 3)  *■/ 

/*  .SET(COTPHT_EOTES_FHG  = 1)  •/ 

/»  .SET  iPRn«IHG_Fl.iG  = 0)  ♦/ 

/*  .SETJTiKE  STiTISTICS_FliG  = 1)  */ 

/»  .SET|TRlci_FliG  = 0)  */ 

/*  .SET|D«F001D_P0DHD_SBITCH  =1)  •/ 

( .tlBEL 

.BO{"aH»IH_PKOCBD1IHE_WlBE  = ■) 


.BO  ("SOBSTR  (9STEB0L,  l,LEIiGTH  (3STEB0L)  -1)  ; ■) 

I .BESSiGEfl] 

.EBPTT  ) 

■PROCEDORE"  .FRB  (2) 

( "I" 

TREE_tARIiBLE_LIST  .ERR  (6,  .SCIBTO  (BiTC!TIRG_P»FE»t";")  ) 
")  ■ .ERR  (64) 

• SET  («ODES_PlRiB_»EITHER_Sf  ITCR  = 2) 

I .EBPTT  ) ~ ~ 

( "OPTIOHS" 

"(■  .ERR  (4) 

OPTIOW_ELEHERT 
*{  OPTIOB  ELEHERT  ) 

■)■  .ERR  (64)“ 

( .EBPTT  ) 

{ .TEST(BSI«  PITER RlL_»riTEER_SBITCn  = 2) 

( .TFST(10DES_PiRSB_BEITHER_SSlTCH  = 1) 

.BESSIGE  (BOf  ~ 

) .EBPTT  ) 

I .EEPTI 

( .TEST(10DES_PiHiB_BEITEEE_SBITCH  = 2) 

.BESSiGE(3lf  “ 

I .FEPTT  ) ) 

( "HECORSIFE" 

.TEST  (BiIB_EITEB»iI_»EITEER_SBlTCi:  =2) 

.ERR  (82) 
r .EBPTT  ) 

SEBI_C010R 

$(  "DECLiRE"  BECLlBE_STiTEBEKT  SFBI_C01.0»  ) 
t B0W_E»D_0*IT 

( "EBB" 

( .IB  .EESS1GF(25)  | .EBPTT  ) 

SEBr_COtOR 
J .BESSIGE  (7) 

.EBPTT  ) 

.PEEE(*^««:")  .ERR(8) 
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*(  .PEEK  ("«?«■)  .BEG 
I $ BOB  EBB  DRIT 
( "EBD" 

( .ID  .BESSIGE (25)  I .BHPTI  ) 

SFBI_COLOK 
I .FBpfl  ) ) ; 

O P TIO  B_EI.EB  B B I : = 

•HUB" 

( .TEST(BiII_EITEE!tlL_REITHER_SBlTCH  = 2) 

• BESSIGE  (79,. SCIBTO  (EITCRIKG_PIPEjri";»)  ) 

I .EBPTT  ) 

.SET(BirB_EXTEPBIL  lEITEER  SBITCE  = 1) 

I "BOTES*  “ 

r "HOBOTFS" 

• SET  (OnTPDT_BOTFS_FLIG  = 0) 

I "BOTRICE" 

I "TRICE" 

.SET  (TRiCE_FLIG  = 1) 

( "STIT" 
t "BOSTIT" 

.SET (IIKE_STITISTICS_PIIG  = 0) 

I "BODES" 

•SIT(B0DPS_PIF1R  BEITHER_SBITCH  = 1) 

■("  .ERR  (4) 

.BDB  .ERE  (67) 

.FRB (60) 

.BOB  .ERR  (68) 

■)"  .ERR  (64) 

I "EITFRBIl." 

{ .TEST(BIIB_EITERBIL_BEITHEH_SBITCF  = 1) 

.BESSIGE (79, .SCIBT07BITCniRG_PlREB I";") ) 

I .EBPTT  ) 

.SET(BII1_EITERB11._BEITEEE_SBITCH  = 2) 

( .BESSAGP(5,.SCIBTO(BlTCia:BG_PlBEB|","|";"))  .EBPTT  ; 

IOB_ERDJDBIT  : = 

* PBOGRAB_nBIT 

( ,PrEK("EBD") 

.BEG 

.RETURB 

( .PEEE("E«««!") 

( .TEST  (ElD_OF_FIl,E_PLiG  = 0) 

.BESSAGE  (26) 

.EEPTI 

.SET  (EBB  OF_FIIE  FLAG  = 7) 

I .EBPTT  ) 

.BEG 

.RETBBB 

I .BESSAGE  (9, .5CIBBT  (";■)) 

.D0("aSTBT  = aSTET  + 1;") 

.EBPTT  ) ; 

PR06RIB_0BIT  := 

.SET  (LABEL_FI.IG  = 0) 

*(  .LABEL  “.SET (LABEL  FLAG  = 1)  ) 

( "PROCEDBRE"  “ 

.TEST(LABBL_FLIG  = 1)  .ERR  (3) 

PROCFDimE_BLOCK  .DO  ("acODBT  (1)  =aC0DBT(1)  + 1;") 


I STiTBHBWT 

I .BBPTl  .HKG  .EKrnUll  ) 


PE0CED08E_B10CK  := 

‘ TBEE_V»RIIBI.e1lIST  .FRR(6,.SCA«T0(MTCHI*G_PiRrBr;«)) 

■)  " -ERE  16H) 

\ .EHETI  ) 

( "RECTO SI»E"  J -EHPTT  ) 

,DO("aEETEL  = aLETEI.  ♦ 1;") 

I*""5eCL»BE"  BECI.»RE_ST»TEHE»T  SEHl^COlOF  ) 

J B0«  E»I>  BUT  . 

( "ETO"  1 -ID  .BESSAGE{25)  I -EBPTT  ) 

.DO  ("91.ETEI.  = 9DEVEL  - 1;") 

SEBI_COLOB 

1 .PEEK 

.HESSAGE(IO)  ) ; 

DECLARE  STATEBEBT  i=  .. 

.EBPTI  .DO("aCODBT|11)  = 8C00»T<11)  ♦ 1.  ) 

1GB0EE_EITR  A_COBB  A S 
( .PEEK  ("LOCAL")  ".BBSSAGE  (27) 

I .THEE 
I .ID  ) 

.ERR  (27) 

*1  IGFOHE  EXTRA_COBBAS 

{ .PEEK  ("LOCAL"!";")  .BESSAGE(59) 

I .TREE 

I .ID) 

.EHR(66,.SCABTO(","|";"))  ) 

"LOCAL"  .ERE  (B3)  ; 


/*  STATEBEBT  TYPES  */ 
/*♦*♦♦»»**♦*♦***♦•♦•/ 

STATEBEBT  := 

"IE"  COBDITIOBAL_STATEBEKT 
t nNCOBDITIOBAL_STATFEEHT 
SEBI_COLOH  ; 

DlICOBDITIOBAL_STATEBEHT  :=  , 

.PEEK ("ESD" I .REG  .BETOBB 

1 "STOP"  ’.DO("aCOTOT(14)  = aCOOHT(m)  + 

! "EETOBB"  .DO("aCODHT(15)  - aCORHT  (15)  + 

I "TRACE"  .DO  ("acODBT  (26)  = SCOOBT  (26)  + 1;  ) 
.TEST  (TEACE_FLAG  = 1)  .ERR  (14) 

( "OPE" 

I "LOR" 

I "uIGL"  , 

I .BESSAGE (15,. SCABTO (";■))  .EBPTT) 

I "ELSE" 

.BESSAGE  (35) 

( "IE"  COHDITIOBAL_STATEHEKT 
1 DBCOBDITIOBAL  STATEBEBT 

1 •(  .PEEK("K«:^K")  I ■»»!>■  ) 
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.BESSAGE  (31) 

I .BESSAGE  (9,. SCABTO  (■;■)) 

.D0("3STBT  = aSTBT  + 1;") 

.EBPTT  ) 

I "DECLARE" 

.BESSAGE  (36) 

DEC! IB E_ST ATEBEIT 
I "BEGIB"  BEGIB_BLOCK 
I "DO"  DO_GRODP 
I "GO"  "TO"  .EPB(42) 

.ID  .ERR  (43,. SCABTO  (■;")) 

.DO("aCOPBT(12)  = aCODBT(12)  ♦ 1;") 

I "CALL"  CALL  STATEBEBT  . , 

I TREE_ASSIGiBERT_STATEHEBT  .DO  ("BCODBT  (16)  = aCODBT  (16)  + 1;  ) 

' laeel\ssigbbebt_statebebt  .DO("acoDBT(i7)  = 1-1;"* 

I "PRBHE"  PRDBEJSTATFBEKT  .DO  ("3COBBT  (18)  = 

j "IBSERT"  ItSERT_STATEBEBT  .DO  ("3C0DBT  (19)  = 3COBBT(19)  + 1,  ) 

I "GRAFT"  ,SET(PROBIBG_FLAG  = 1) 

( "IBSERT"  IBSEET_STATFBEHT  .DO  ("3C00BT  (21)  = aCODBT  (21)  + 1;") 
I GRAFT_STATEEEBT  ) 

I "ADYABCE"  ADTABCFJSTATEBBBT 

.DO{"3CODBT(56)  = BCODBT(56)  +1;")  ,T>,  * 

I "ORDER"  ORDER  STATEBEBT  .DO  ("SCOOBT  (22)  = 3COOBl(22)  + 1,  ) 

I "READ"  EEADJSTATEBEBT  -DO  ("aCODHT  (23)  = aC0TOT(23)  + ^ 
i "BRITE"  BBITE  STATEBEBT  .DO  ("3CODKT  (24)  - acOOHT  (24)  ^ 

I "DEFIBE"  DEFIBE_STATEREBT  .DO  ("acODBT  (27)  - BCOOBT  (27)  ♦ 1;  ) 

I ARITEBETIC  ASSIGHBEBT_STATEBEBT 

.DO("aCODBT  (25)  = 3COOBT(25)  + 1;")  ; 


/***************/ 

/♦  BEGIB  BLOCK  ♦/ 

/♦*♦♦♦**•**»•*♦*/ 

BEGIB  BLOCK  :=  , 

.EBPTT  .D0("3C0DBT(2)  = 3C00BT  (2)  + 1;") 
,DO("aLETEL  = aLEYFL  + 1;") 

SEBl  COLOB  _ 

( "DECLARE"  DECLAPE_STATEBEBT  SEBI_COLOB 
I .EBPTT  .BESSAGE  (11)  ) , 

$(  "DECLARE"  DECLAEE_STATEBEST  SEBI_COLOB  ) 
$ BOH_ERD_DHIT ' 

( "EBD"  ~ 

I .PEEK  ("<««!") 

.BESSAGE  (12)  ) 

( .ID 

.BESSAGE  (25) 

I .EBPTT  ) 

.DO("aLETEL  = 3LEVFL  - 1;")  ; 


/»»*♦♦*****♦*/ 

/*  DO  GBODP  »/ 

/*♦♦♦*♦*♦*•**/ 

DO  GBODP  ; = 

.EBPTT 

.DO("3BEST  = 3BEST  ♦ 1;") 


r 


( "WHItt"  VniLE  CIWSE  .DO  |■^COIJ■T |5)  = SCOOTtT  (5)  ♦ 1;") 

I "FOR"  “ 

( "*X1" 

( "SOBBODES"  SDBBODE_a.iCSE 
.DO|"acOOBT(6>  = aCOnMT(e)  + 1;») 

I COHBimTTOi_CX«?SE 
.BBT  UBB 

I .EHPTT  .HESS»GE|19,.SCJlBT0r;"J)  ) 

I .HESSBGE  (19,. SCIBTO !■;■))  .EBPTT  ) 

J IfCBEBEBT  CLKDSE  .DO  ("aCODBT  (9)  = aCODBT  (4)  ♦ 1;") 

( .KBPTI  .DO("aCOBHT(3)  = aCODBT(3)  ♦ 1;")  ) 
DOJBODT_TBBODGH_E«D  ; 

WHILE  CLKHSE  := 

Tehpk 

■(■  .ERE  (9) 

BOOLEl»_EIPRESSIO!l  .ERR  (13  , .SCRHTO  (■)■(■;■)  ) 

■)"  .ERR(64,.SCiITO  (■:■)  ) ; 

snEHODE_CLlDSE  : = 

.FBPTI 

■OE“  .EER  (20J 

SOET_TEEE  BODE  .EER  (21,  .SCABIO  ("DSIHG"  (■;■)  ) 

"DsiBG"  Terr  (22) 

.TREE  .EBB(23,.SC»»TO(*;")  ) ; 

COBBIBATIOBJCLIOSE  := 

( "COBBIBiTIOBS"  .DO  ("aCODHT  (7)  = aCODBT  (7)  ♦ 1;") 

I ■PERHDTATIOHS"  .DO  ("BCODHT  (8)  = acODBT  (8)  + 1;«)  ) 

•TEST  (COHB_OE_PEEB_LOOP_FLAG  = 0)  .ERE  (77) 

.EET  (COHB_OR_PERH_XOOP_FL»G  = 1) 

■OF"  .ERR  (20) 

SOFT  THEE  BODE  .ERR  (21,.SCAITO("TAKEB"  (■;■)  ) 

"TAKER"  Tepf(36,.SCABT0(";")  ) 

AHITH  EiPRESSIOR  .ERR  (39,.SCABTO  ("AT"|";") ) 

"AT"  ~.ERE(18,.SCARTO("A"|"TIHE"|";")  ) 

■A"  .EBB(40,.SCARIO("TIBE"|";")  ) 

■TIHE"  .ERE  (41) 

DO_BODT_THRODGE_EID 
.SET(COHB_OR_PERH_XOOP_FXAG  = 0)  ; 

IHCEEHEBTJCLADSE  := 

.ID 

{ “=■ 

.HESSAGE  (19,  .SCABTO  (";■)  ) 

.EBPTE 
.RETDEB  ) 

ARITH_EXPRESSrON  .ERE  (39  , .SCABTO  (","|  "TO")  "BT"(  ";")  ) 

K(  ","  AEITH  EIPRESSIOH  .ERR  (39,  .SCABTO  (","  ("TO"  | "BT"|"  ;■)  ) ) 
( "TO"  ~ 

ARIT  H JBXPBESSIOH  .FEE (39 ,, SCIRTO ("BT" (";■)) 

( "BT" 

ARITn  EXPEESSICB  .FEE  (39  , .SCABTO  (";■)  ) 

I .EHPTT  ) 

*(  ARITH  EXPHESSXOH  .ERR  (39,  .SCABTO  (","(";"))  ) 

I .EHPTT) 

( "WHILE"  WHILEJCXADSE 
I .EHPTT  ) ; 
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DO_BODT_TFRODGH_EBD  : = 

.EHPTT 

.PEEK(";»)  .ERR  (19,  .SCABTO  (•;■)) 

* BOB_FBD_OBIT 

.DO  ("a  BEST  = aWEST  - 1;") 

( "EBD" 

r .PEEK  ("rKK F")  .HESSAGE  (37)  .EHPTT  ) 
( .ID  .HESSAGE (25) 

) .EHPTT  ) ; 


/*•*•* **9**9***«****»«***«/ 

/*  COBDITIOBAL  STATEHEBT  •/ 


COBDITIOBAX  STATFHEKT  ;= 

.EHPTT~ 

BOOXBAB_EZPRESSIOB  .ERE (13, . SCABTO (“TEFB" |";")  ) 
( .PEEK  ("THEB") 

I .HESSAGE(29) 

I .HESSAGE  (26 , .SCABTO  ("TEEB"  I ";  ")  ) 

.EHPTT  ) 

.DO("asTHT  = 8SIHT  + 1;") 

( "TEEB" 

( STATEHFBT 
I "EBD" 

.HESSAGE  (3C) 

SEHI_COLOH 
I .PEEK("rrrr") 

.HESSAGE  (30) 

I .HESSAGE  (9,. SCABBT  (■;•)) 

.DO("aSTHT  = aSTHT  ♦ 1;") 

.EHPTT  ) 

I .HESSAGE  (32,  .SCABBTf";")) 

.DO("aSTBT  = aSTPT  + 1;") 

..EHPTT  ) 

( "ELSE"  .DO(«acOOHT(10)  = acODRT(IO)  + 1;") 

( STATEHEBT 
I "EBD" 

-HESSAGE  (31) 

SBEI_COXOH 
f .PE£K("KK«:»:") 

.HESSAGE  (31) 

I .HESSAGE  (9, .SCAIBI  (■;■)) 

.DO("aSTHT  = aSTHT  + 1;") 

.EHPTT  ) 

1 .EHPTT  .DO("aCODBT(9)  = 3C00KT  (9)  ♦ 1;")  ) ; 


/*******»*««««*«*** ^ 

/*  CALX  STATEHEBT  */ 

/*****•"•«**•••*«•* / 

CAXL_STATEHEBT  : = 

.EHPTT  .DO("aC0DBT(13)  = aCODHT  (13)  ♦ 1;") 

.ID  .EHR(44,.SCABTO("("|";")) 

( •(■  IGH0EE_EXTBA_C0HR1S 

CAXX_ARGDHEBT  . ERR  (45 , . SCABTO  (","  | H ATCEIBG_PAREB  I "; ")  ) 


c» 


$(  IG!IOBE_EITB»_COHI!»S 

.BESSiGE(59> 

I CUL  lEGnilEHT 
I .EHPTT 

.BESSJIGK (l»5  , . SCA1IT0  ■ |B»TCHI1G_P»BEB  | ■ ; ■)  ) ) ) 

")  ■ .ERR  |64) 

1 .EHPTT  ) ; 

C4I1.  BEGOBEBT  ; = 

^HBRD_TBEE_«ODE 
I .PEEK  ("LIBEl") 

BRITS  EIPRESSIOH 

( .TE?T(BRITB_0PEBBTI0H_FL1G  = 1) 

.BESSBGE(78) 
r .EBPTT 

.BESSBGE  (45)  ) 

I BHITH_EIPRESSIOE 

( .TEST(BR1TE_0PERBT10B_PIBG  = 1) 

• HESSBGE  (78) 
r .EBPTI  ) ; 


/*****•*********•*******«*••**/ 

/*  TBEE  BSSIGBEEBt  STBTEBEHT  */ 
/»****•**«*»*****•********#**«/ 

THEE_BSSIG1HE!IT_STBTEBE*T  : = 

EBRDJTHEE^IIODE 

( 

f .BESSBGE(9,.SCBPTO(";“))  .EBPTT  .HETORW  ) 
S1BPLE_EXPRESSI0H  .ERR (21 , .SCBKTO («;") ) .EBPTT  ; 


/*  tBBEL  BSSIGBBEBT  STBTEBEHT'  ♦/ 

/*****«*****«*«********«*•***•*/ 

IBBEI  BSSIGHHEHT_STBTEHBII  := 

Tebptt 

■("  .ERR  (86) 

EBP!»_T»EE_HODE  .ERR  (56, .SCBBTO {BBTCEIHG_PBEEHI"="| ";") ) 
■)■  .EBF(64,.SCBHTO("=“|";") ) 

I Ush 

I . BESSBGE  (9,. SCBHTO  (";■))  .EBPTT  .BETDRII) 
SIBPtE^EIPRESSIOH  .ERR  (92,  .SCBHTO  (■;■) ) .EBPTT  ; 


/♦♦*»•*♦♦♦♦•**•**»»•/ 
/»  PRDHE  STBTEBEHT  */ 

/******«************/ 

PRBHF  STBTEBEHT  := 

Tebptt 

.SET  (PR0H1HG_E1BG  = 1) 
1GH0RE_EXTRA~C0BBBS 

SOFT  TREE  HODE  .ERE  (21 , .SCBHTO  (";*)  ) 
$(  «7"  IGHORE  EXTRA  COHBBS 

( .PEEK(-;"r 


.HESSBGE  (59) 

■ I SOET_TRBB_HODE 
I .EHPTT 

.HESSBGE(21,.SCBHTO(";"|",")))  ) 
.SET  (PRnHIHG^^ELBG  = 0)  ; 


/******************* / 

/*  GRBET_ST1TEBEHT  V 

/»*••*•••••««*****•*/ 

GEaPT_STBTEBBHT  := 

.DO  ("aCODHT  (20)  = aCODHT(20)  + 1;«) 

.EBPTT 

SIBPLE  EXPRESSIOH  .ERR (21, .SCBHTO ("BT")";")) 
.TEST  (BELSDCE_ELBG  = C)  .ERR  (87) 

.SET(PPOHIHG  FLAG  = 0) 

"BT"  .ERR(18)T 

EBRD_TREE_HODE  .ERR  (21 , .SCBHTO (■;") > .EBPTT  ; 


/*********************/ 
/*  BDYBHCE  STBTEBEHT  •/ 

/*♦♦♦♦•♦♦•♦♦♦♦*♦♦♦♦♦♦♦/ 

BDTBHCE_STBTEHEHT  ;= 

.EBPTT 

.TREE  .ERE  (23,. SCBHTO  (";■))  ; 


/********«*******•**/ 

/•  ORDER  STBTEBEHT  */ 
/**«•••*•****•***•*•/ 

ORDER  STBTEBEHT  J= 

Tebptt 

S0ET_TREE_10DE  .ERR  (21,  .SCBHTO  ("BT"  ( ";  ")  ) 

( "BT" 

. IGHORE  EXTRB_COBBBS 

( .PEEK(";")  .HESSBGE(84) 

I ORDER  BRGDBEHT  ) 
t(  - 

( .PEEK(","|";")  .HESSBGE  (59) 

I ORDER  BRGDBEHT  ) 

I .PEEK (.ID)"-")  -HESSBGE (60) 

ORDER_BR60BEHT  ) 
t .EBPTT  ) ; 

ORDER  BBGDHERT  := 

7 I .EBPTT  ) 

( "SEIEHEHT"  ! .ID  ) .ERE (61 , .SCBHTO ("," |“;") ) 

I(  SORT  OR*I.IEirB_BT_LBBrI. 

I " (■  EOET~ODBlIEIER_BT  SDBSCBIPT  ■)  ■ .ERR  (64)  ) 


yr*««**«*  ****•••••••**/ 

/♦  liSEHT  STBTEBEHT  ♦/ 

/ft****  *************** / 
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mSJRT_STHTEHINT  : = 

•EHPTI 

SIHPLE_EIPEESSIO!f  -EEE  (21 , .SCASTO  ("BEEOSF"  (";")) 
•TEST ( III, SnCE_ELSG  = 0)  .EPE  (B8) 

.SET  {PEnPI»G_FL»G  = 0) 

"BEFORE"  .EES  (17) 

ESRD_TR  EE_HODE  .EPE  (21,.  SCAHTO  (■;■)) 

.TEST(DBODAI.IFIED_TBEE_FIAC  = 0)  .EES  (69)  .EKPTY  ; 


/♦★******♦**♦****♦*/ 

/*  READ  STATEBENT  */ 

/»*♦♦*******♦**»♦**/ 

RFAB_STATEREKT  := 

1GEORE_EXTBA_COBBAS 
FItE_COHPEESSED_OFTIOKS 
( .FEEK(";")  .HESSAGE(63)  .FBETT 
I READ_SLEBE»T  ) 

S( 

( .FEFK  (";"(",")  .HESSAGE  (59) 

I BEAD  ELEHBHT  ) 

( . PEEK  (TxDI, TREE)  .HESSAGE  (60) 
READ_ELEFE!fT  ) ; 

FllE_COHPEESSED_OPTIOBS  := 

{ "FILE" 

"(“  .ERR  (4) 

.ID  .EER(72,.SCAH TO  (")  ")";")) 

■)  " .TEH  (64) 

I .EHPTT  ) 

( "COHPBESSED" 
r .EHPTT  ) ; 

EBAD_ELBHENT  := 

.ID 

I EARD_TEEE_HCDE 

I .BESSAGE(63,.SCAHT0(","|":"))  .EHPTT 


/*  WRITE  STATEBENT  •/ 

/**♦•♦***♦♦****♦***♦/ 

HEITE_STATEBEHT  : = 

IGHOEE_EXTE  A_COBKA  S 
FILB_COHPR  ESSED_OPTIOBS 
( .PEEK(*;")  .HESSAGE (63)  .EHPTT 
I BBITE_ELEHENT  ) 

$ ( 

('.PFEK(";"|",")  . HESSAGE  (59) 

I WEITE_ELEHEI«T  ) 

) .PEEK  (.ID  I. TREE)  .HESSAGE  (60) 

WEITE_ELBHEST  ) ; 

WBlTB_BLBHEFt  := 

"LABEL"  LABEL_STR1HG 
I .STRING 
I .ID 


f' 


I I— ' 


t 
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I soft_tfee_hcde 
I .HESSAGE  (63,  .SeANTO(","i";‘')1 


.EHPTT 


**♦****•*»«■*♦♦*/ 

/*  DEFINE  STATEKEKT  »/ 

DEFI»E_STATEHENT  := 

.EHPTT 

.THEE  .ERR  (23 , . SCAHTO  ("A  S"  | " ;■)  ) 

■AS"  -ERR  (33) 

HABD_TREE_NODE  .ERR  (21 , .SCABTO  ("5")  ) ; 


^*ARITRBETIC  ^SSIGHHEHT^STATEHEHT^V 

AEITLHETIC_ASSIGBBEHT_S  TATFHER  T : = 

• .ID 

^ fl  = M 

I .HESSASE  (9,  .SCARIO  (■;’=)  ) 

.EHPTT 
.REIDKB  ) 

AEITE_FEPEESSION  .ERR  (39  ^ .SCAHTO  (";")  ) J 


/♦  GEHEPA.L  EIPRESSIOH  */ 

SIHPLE  EIPRESSIOH  ;= 

,,'j  .SET  (ALLSOCu_TLAG  = 0) 

( SOET_TREE_HODE 

.SET  (TREE_STBIHG_ARITn_S¥ITCi:  - 1) 

( CHAR_STEIHG 

.SET  (TREE_STEIHG_1RITE_SWITCP  = 2)  ) 

{ .PEEK  I"**") 

.SET  (TJHPOnaD_FODKD_S¥ITCE  = 2) 
ARXTB_EIPHESSIOH 

.SET  (TBEE_STBIHG_AEIT5:_SPITCn  = 3) 

( .EHPTT  ) 

I ARITH_EIPRESSI0R 

.SET  (TREE_STBIHG_APITtT_S¥ITCi;  = 3)  ; 


/*  BOOLEAH  EIPRESSIOH  »/ 

BOOLEAH_BIPRESSIOH  : = 

B00LEAH_PRIHART 

**  BOOLEAH_PRIBART  .ERE(13,.SCAHT0("THEH"!"6"I"!"I";"))  ) 
B00LEAH_PR1BAET  := 

If  ^ 

booleau^expkesstok 


.EEE  (13  , .SCAKTO  (HiTCHIHG_PAEES  t "TEEH"  1 "G"  I " ( " I " I ■•)  ) 

")"  .FEE  (64) 

} 

"(■  ..EPE(73) 

( BOOI.FXS_ZIPEESSIOE 
1 .EHPTT  “.HEG  .EFTDBH  ) 

")  " .EES  (64) 

I SIHPI.E_EXPEESEIOE 

.DO("I:Sa_I.EPT_SBITCH  = TEEE_STBIHG_AEZTE_SRITCE;") 

{ TEEEJBEIAIIOE 

.SET  (TSa_EEliTIOB_SEITCE  = 1) 

I AEITH  BELATIOK 

.SET  (TSA_EFL1TI0S_SEITCH  = 3) 

1 .EHPTT  *' 

.EESSAGE(71)  ) 

SXBPLE_EXPHESSIOH  .BEE  (13 , .SCAHIO  ("THEE"  1 "6"  I "I”  1 ";")) 
.P0("TSA_SIGET_SBITCII  = TBEE_STBIHG_AEITK_SErTCt:;  ") 

detect  tTpe  COEVEBSIOSS  ; ~ 


AEITH_EELAtIOH  := 

n^fl  I I «=»i 

; 


I »>=»  I »>■  I I 


TEFE  EELATIOF  := 

~(  I "HOT"  I .EEPTT  ) 

( "IDESTICAI"  ( "TO"  I .EfePTI  ) 

.DO  ("StCOGHT  (51)  = acODHT  (51)  + 1;") 

I "SUBSET"  ( "OF"  I .EHPTT  ) 

.DO  ("aCOUHT  (52)  = 3C0BHT  (52)  + 1;") 

I "EEBKEHT"  { "OF"  | .EBPTT  ) 

.DO("SCODST(53)  =3C0DHT(53)  + 1;") 

1 .EBPTT  .HEG  .EETDEH  ) ; 

DETECT_TTPB  CONVEESIOSS  := 

.TEST  (fsA_BETATIOH_SHITCB  = 1) 

( .TEST  (TSA_LFFT_SH1TCIT  = 2) 

.DO("aCODKT(47)  = SCODHT  (47)  + 1;")  ■ 

I .TEST  (TSA_LEFT_SHITCE  =3) 

.DO("aCOUHT{49)  = aCO0BT(49)  + 1;") 

1 .EBPTT  ) 

( .TEST(TSA_FIGET_S»ITCE  = 2) 

.D0("aC0UHT{47)  = acOUHT  (47)  + 1;") 

I .TEST  (TSA_EIGET_SH  ITCH  = 3) 

.DO  ("aCOUHT  (49)~=  3COUBT(49)  + 1;“) 

I .EBPTT  ) 

I .EBPTT  ; /♦TO  BE  EXTEHDED  */ 

/*♦*♦♦*♦*»*♦*»**♦♦♦♦/ 

/♦  TEFF  EXPBFSSIOH  ♦/ 

y*******************/ 

HA1D_THEE_N0DE  ; = 

("SHDII"  .BESSAGE(16)  | COHBIHATIOH_OR_PFBHDTATION_TEEE  1 .TBEE) 
.DO("aCOimT  (2P)  = aC0DNT(28)  + 1;") 

.SET  (DSQDAXIFIED_rSEE_Fl.AG  = 1) 

£(  "."  HAHD_ODALXFIEE_BT_iABEL  .SET  (DHOnAXXFXED_TBEE_FlAG  = 0) 

I 

HARD  QnALIFXEE_BT_snESCRIPT 

")  " “.EEH  (64,  .SCAHTO  ("=■  | "."1 "(")";")  ) 
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.SET  (UHQOALIFXED_TEFF_ELAG  = 0)  ) ; 

SOFT  TBEE_HODE  : = 

( COHBIHATIOH  OB  PEBPUTATIOH_TEEE  | .TEFF  ) 

.D0("3C0DKT(29)  = aC0UHT{29)  +1;") 

.SET  (aHQ0AlXFXED_TBEE_FlA6  = 1) 

t(  SOFT_QUALXFIEE_BT_I.ABEL  .SET  (OBQrALXFXED_TBEE_FXAG  = 0) 

1 "{" 

SOFT_0UAXXFXEE_BT_SDPSCBXET 

.kB(64..SCAHTO("-"l».«t")"l*':"l"+"l''-"1"*”l"/"I“=^*"I"B"l"l”l 
m^n  1 11^"  I n=n  | | ■<="  | «>="  | ( "^>="  ) "HOT")  ) 

.SET(DHQnALXFIED_TBEE_FXAG  = 0)  ) ; 

C0EBIHATX0H_0H_PEEHDTATI0H_TEEE  : = 

( "JCOHBXHATXOH"  I "PEEBDTATXOH"  ) 

* (S  "HEIT"  ! "lAST"  I "FIRST"  I "AIL"  1 "FIRST:"  ) "ALL:"  ) 
.HISSAGE(75,.SCABTO(HATCHXHG_PAREH  ) ";")) 

I .EBPTT  „ _ . . 

AEXTi:_EXPBESSXOH  .ERE  (39  , .SCAHTO  {HITCHXHG_PAEEK  I »;"))  ) 

«)  " .FEE  (64) 

I .BESSAGE(74)  .EBPTT) 

{ .TEST(PEDBIHG_FLAG  = 1) 

.PEER("."  r ■(")  .ERP?76) 

)/  .EBPTT  ) ; 

HARD  OOALXFXEE_BT_LABEL  := 

BODE_LABEL  .DO  ("acODHT  (30)  = BCODHT  (30)  + 3;") 

I "f"  IHDXEFCT_C5:AE_ETEXNG  .do  ("aCOUHT  (31)  - aCOUEU(j.;  + 1;") 

I .BESSAGE(49)  ~.EEPTT  ; 

SOFT  ODALXFIER_BT_LABFL  : = 

HODE_LABFL  .DO  ("BCOUKI  (37)  = acODKT  (37)  + 1;") 

I 

( .TEST{PEHHIHG_FLAG  = 1) 

.SET(PEDHIHG_FLAG  = 0) 

THDTRECT_CEAE_STFXHG 
.SET  (PBHHIHG_FLAG  = 1) 

I XHDXBFCT_CHAR_STEIHG  ) 

.DO("aCOHHT  (38)  = aCOHBT(38)  + 1;") 

1 .EBPTT 

.eessage(49,.scahto("."|"  ("  I";"))  ; 

HODE_LABEL  := 

"HFIT"  .HFSSAGF(50) 

I "LAST"  .BESSAGE(52) 

I "FLEET"  .HESSAGE(58) 

1 "FXBST:"  .2ESSAGF(90) 

I "ALL"  .HESSAGF(70) 

I "ALL:"  .HESSAGE(91) 

I "LABEL"  .HESSAGE(54)  LABFL_STPXHG 
I .ID  ; 

LAED_QUAXIFXEE_BT_SnBSCPXPT  : = 

"HEAT"  .DO  ("SCODHT  (35)  = acODHT  (35)  + 1;") 

) "LAST"  .D0("BC0UHT(34)  = aCODHT(34)  + 1;") 

I "FIRST"  .DO  ("SCODHT  (32)  = acOOHT  (32)  +1t") 

I "ALL"  .BESS AGE (89)  .EHPTT 


I "FltST;"  .DO  |■8C00»T  (33)  = aCOD»I(33)  ♦1;") 

BOOLDXW  EIPHESSIO*  .EER  (13,  .SCJltTO  (H1TCEI«G_PBEE»  ( "I  •»")  ) 

I •lU.:"  ~.HESSBGE  (3«) 

BOOLBJl*_ETERESSIOII  .EEE  ( 13 , .SCBWTO  (E1TCHI»G_P*RE> 

I .EESS»GE(85) 

i:HDIEECT_CHiR_STR3:>G 

I BSITH  EXPEESSfoR  .DO  ("aCODHT  (36)  ^ 8C0PRT  (36)  ♦ 1;«) 

I .BESslGE(39,.SCBIITO(HiTC5IIG_PAEEH|*;"|". ■(•,"))  .EBPTT  ; 

SORT  QDBIIFIER  BI_SDBSCHIPT  : = 

“■REIT"  .HESSIGE(51)  .EBPTT 
I "LIST*  .DO  (•aCODBT  (03)  = »0)D»T  (43)  ♦ 1;") 

I "PIRST"  .DO("SCODIT(39)  = aCODlT  (39)  ♦ 1;") 

I "MX*  .HESS»GE(89) 

I "FIRST:"  .DO("aCODBT(40)  = 9C0DBT (40)  + 1;") 

( .TEST(PRDBHG_FLSG  = 1) 

.SETfPROBIBG  FX»€  = 0) 

BOOLEia  EIPEESSIOB  .ERR  (13 , .SCllTO (BRTCHTBG_P»EEB| ":"("." I ",") ) 
.SET  (PED»IWG_FLiG  = 1) 
t BOOXEAR_EIPEFSSIOB  ) 

.ERR (13, .SCBBTO (HBTCHIHG_P1REK|" I "S ") ) 
t "BIX:"  .DO("aCODBT(42)  = BCOOBT  (42)  + 1;") 

( .TEST  (PROBIBG  FXBG  = 1) 

.SET(PRDHIHG  FXBG  = 0) 

BOOIEBB  EXPRESSTOH  .ERE  (13,.SCB»TO  (HBTCEIBG_PBEE1I|";"("."I",")  ) 
.SET  (PRnRI»G_FXBG  = 1) 

I BOOXEBH_EIPRESSroH  ) 

.ERE  (13,.SCBBTO(BBTCHr«G_PSREW|";"|"."?",")  ) 

I ■*■  .BESSBGE(85) 

( .TEST(PRnSlRG_FXBG  = 1) 

.SET  (PRORIRG^FXBG  = 0) 
mDIFFCr_CKBR_STRI»G 
.SET  {PRD8IHG_FXBG  = 1) 

I IRDIEECT  CHBR^STHIBG  ) 

I ( .TEST(PRDWniG_FXBG  = 1) 

.SET  tPHOBHIG  FXBG  = 0) 

BKITE_EIPRESSIOH  .ERR (39, .SCBRTO (BBTCHIHG_PBRE1| I"."!" ,") ) 
.DO  ("9C00BT  (44)  = 9C0DBT  (44)  + 1;") 

.SET  (PEn»IHG_FXBG  = 1) 

I BRITE  EXPHEs¥iO»  .DO  ("SCOOHT  (44)  = aC0D»T(44)  + 1;")  ) 

I .BESSBGE(39,.SClHTO(BBTCi:iIG_PlEEH|";"(". "(","))  .EBPTT  ; 


/***"*****«*«*44i4*****/ 

’ /•  STFIBG  EIPEESSIOB-  */ 

^***4i***»**«*********/ 

CHBE_STEIBG  := 

.STRIBG 

I SOFT  THEE_BOD* 
t "LBBEX"  XBBEX_STHIBG  ; 


! 


f 


XBBEX  STRIBG  := 

-EBPTT 

"("  -EHR(R6) 

SOFT_TREE_MODE  -ERR  (56,  .SCBBTO  (EBTCHIBG_PBBEH(";")  ) 
") " .ERR  (64)  ; 

IHDIBECT_CERH_STR1BG  := 
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.EBPTT 

( "XBBFX"  XBBEX_SIRIBG 

I ■(" 

( SOFT_TREE_BODE 
I "XaSEX"  “ 

.BESSBGE(62) 

XBBEX_STRIBG 
I .FBPTT 

.BBSSBGP  (62,  .SCBBTO  (BETCEIBG_PBFBB  (■;")  ) ) 
•)"  .ERR  (64) 

I .EBPTT  .BESSIGF  (62,. SCBBTO  (■:"))  ) ; 


/*  BEITBBFTIC  EIPEESSIOB  •/ 

^•***«**********04**««**«/ 

BRITH_EIPEESSIOB  := 

.SET(BEITE_OPFRBTIOB_FXBG  = 0) 

BRITE  TERB 

}(  ( ■+■  I ■-■  ) .SET(BPITH_OPFRBTIOB_FXBG  = 1) 

*(  ("♦"(■/"I"**")  .EESSBGE(46)  ) 

( .PEEK  (•:"  I")  •!■»")  .BESSBGE(46) 

I BRITH_TERE 

I .EESS1GE(47,.SCBBT0("+"|"-"|":"))  -EBPTT  ) ) ; 

BElTnjTEEB  := 

BRITB_FBCTOR 

j I ) .sET(BPITi:_OPEHBTIOB_PXBG  = 1) 

t(  ("*"|"/"|"**")  .EESSBGE(46)  ) 

{.  .PEEK(";"r)“l".“)  -BESSBGE(46) 

I BRITK  EBCTOR 

) .EESSBGE(47,.SCBBTO("+"|"-"|"*"l"/"l";"))  .ERPTI  ) ) ; 

BRITB  FBCTOE  := 

Xetth  PRIBBRT 

t(  .SET  (IHITE_OPEBBTIOB_FXBG  = 1) 

${  (i>«R  I I ■!«*••)'  ,bESSBGE(46)  ) 

( .PEEK(";"(")"I",")  .EESSBGF(46) 

) BPITH  FBCTOE 

) .BESSB6E(47,.SCBHT0("+"|"-"I"*"IV"I";"))  -EBPTT  ) ) ; 

BBITH_PBIHBET  := 

■BOBBER"  .SET  (BRITE_OPEEBTIOB_FXBG  = 1) 

■(■  .ERR  (4) 

SOFT_TREE_BODE  .ERE  (4B,  -SCBBTO  (BBTCRIBG_PBRFB  (";  ")  ) 

■)•  .ERE  (64) 

I "XBBEX"  XBBEX_STHIBG  .DO  ("SCODHT  (48)  = »CODBT(48)  ♦ Ij") 

I .ID 

I .SET  (BRITK_OPEHBTIOH_FXBG  = 1) 

.BOB 

I SOFT_TEEE_BODE  .DO  ("acODBT  (46)  = 8CODBT(46)  + 1;") 

. 

BRITE_EXPRESSIOB  .ERR  (39,  -SCBBTO  (BBTCHIBG_PBREB  ( ■;  ■) ",")  ) 

■)■  Terr  (64)  .set(bhitb_opesbtiob_fxbg  = i) 

[ .TEST(DBEODHD_EOOBD_SBITCi;  = 2) 

.SET  (0BF0DKD_E0DBD_SBITCR  = 1) 

t ( ■♦"  I ■-■  )■ 

BRITir  PRIBBRT  .ERE  (47  ,. SCBBTO  ("♦■  ("-"t  "•"!  "/"(":")  ) ) 


/*  HISCEtLlHEOOS  ♦/ 

/*****************/ 


XGIOBK  FITR*  COHBIlS  := 

.EBPII  " 

$(  ■,»  .H«SS11GE|59)  ) ; 

SBBI  COIOB  := 

“.PEEK  (■«««■) 

I .EBPTT 

.PEEK*";")  .ERR  (65,  .SCSETO  (•;")) 

.DO(«8STBT  = aSTBT  ♦ !;■) 

( I .lEPTT  ) ; 

TREE_T»RI»B1EJLIST  : = 

IGBORE_EITE»_COHE»S 

( .TREE  I .ID  ! .EBPTT  .BEG  .RETBE?  j 
S(  IGEORE  BXTRi_c6BBRS 

( .tret 

r 

I .PEEK  ("J  ■!■;■)  .BESS1GE(59) 

I .EBPTT  .HESSiGE(66,.SClllTO(","|“;"|HITCirtBG_P»REB)))  ) 

.EBD 
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/♦  ERROR  MESSAGES  */ 

DECLARE  3ERR0R_HESSAGE  <10)  CHAR(60)  VARYING  STATIC  INIT( 
•StPDINTER  NAME  CONFLICTS  WITH  TREE  NAME  USED  ELSEWHERE* t /*01*/ 
•S:OUTPUT  STACK  LEFT  NONEMPTY',  /*OZ*f 

•SSPROCEOURE  NAME  CONFLICTS  WITH  VARIABLE  NAME  USED  ELSEWHERE*, 
*N:P0SSIBLE  USER  ERROR:  POINTER  USED  OUTSIDE  OF  SUBNODE  LOOP*, 

'NSPOSSIBLE  INSERTION  BEFORE  ROOT  NODE*);  /♦OS*/ 


Fig. 


1.4-1  Error  Messages  for  PLANS  Code  Generator 


.option  1IST(PD1CF_C0DP=TES,  PRI1T_C0DE=1I0) 

.1DG_GhIb  PIFSPH  (,lHaTI»L_CODr=SPHDCL,  .Finil.JC01>B=SPHBBP) 

/*  XFCLDBES  OPIT  TREE  iSSIGIlHElIT  »HD  PBOTE  BPPIICBTIOW  OP  "ILlt"  */ 
/•  STBTISTICS  TFBOnGB  40,  56  •/ 


/•  BISIC  PBOGBIH  STPOCTBEE  V 

/*•♦•*♦**♦•*****♦*****•*•••*/ 


PMSPH  1= 

/*  FMG  T»ITHI.IZBT10ir  ♦/ 

/**  .SET  JFIEST_PRTBAET_FOnH!>_PinG  = Oj  •♦/ 

/•»  .SETIBAIB  EXTEFllAt_S«ITCB  = 1)  *♦/ 

/**  .SETfBOEBAL  BEFGE_S«ITCH  = 1)  *»/ 

/*♦  .SET  (OOTPBtIhOTFS_FLAG  = 1)  *V 

/••  .SET(PEPIOD_ALREABT_FOnHD_FI,AG  = 0) 

/••  .SEHSET_S0FT_L1BK_FLAG  = C)  *•/ 

/*»  .SET  (TAKF_STATISTICS_FI.AG  = 0>  •*/ 

/**  .SET (TRACE  ALREADT_ODTFDT_FLAG  = 0)  ••/ 

/**  .SEIfTPiCElFLlG  = C)  ♦•/ 

/*  BAIB  PEOCFDORE  */ 

•XABEL 


.SAT  ("PUT  FIXE  (STATIST)  EDIT(***H")  .CAT  (»,"••)  (A)  ;") 

.SAT(») 

,SEAECF_BX0CK  .IF_BFB (1,2,"PD"> 

.DO{"PEOCEDnBE_HABE  = SOBSTB  (aSTBBOX.I.XEBGTH  (SSIBBOX)  - I);") 

.DO  (■aPAGB_BPAD  = BPAGE_HEADM‘  OF  PROCEDORE  • | |PF0CED1JBE__BABE;") 
■PEOCEDOBE"  .OOT  (•) 

( "(»  I","  .ODT{*) 

PEOCFDOBE_ARGGBFBT 

5(  1.^1.  itt^n  .ODT(",")  PBOCEDDEE_ABGnBEFT  ) 

")  " .ODI  (♦> 

) .FBPTT  ) 

( "OPTIOBS  " . 

( "{"  I .EBPTT  ) 

OPTICH_EXFRERT  5(  ",*•  OPT10«_EXEBEHT  ) 

**)  ** 

( .FBFTI  ) >- 

.DO("»OBEAX_BEEGE_SBITCF  = HOEBAX_BERGE_SBITCF  + !;■) 

( .TEST{BAIB_EXTER1IAX_SB1XCE  = 2) 

.OUT  (#) 

•DO ("HOE BAX_BFRGE_SBITCF  = HOPHAX_BERGF_SBITCB  - 1;") 

( "EFCRPSITE"  .ODT("  EECURSITE") 

.IH1T_BX0CK  .FIHD_HEXT(1,1,"P")  .EHTEP  (2, 1,  "B") 

I .FBPTT  ) ~ 

•00T("  EEOEDER;") 

.OOT  ("SIHCXDDE  PXARS  (MODES)  ; ■) 

•OOT  ("TTHCXODF  PXAHS  (ISTOEAG)  ;") 

.OOT  ("XIHCXCDE  PXAHS  (XEHTRT)  ;") 

I .FBPTT  .ODT{«) 

.DO("HOPBAX  HERGF_SBITCF  = HOFBAX_SFPGE_SBITCH  - 1;") 

.OOT  ("  OFTIOHS  (BAIH)  ;") 

.OOT  ("DECXARE  aHDHBEBjOF_BODES  FIXED  BIHAET  (15,0)  STATIC  IHIT  (") 
.DO("CAXX  aoOT  (BODES)  7")  .OOT  (")  ;“) 

.OOT  ("DECXARE  aHCHBEE_pF_XABEXS  FIXED  BIHAET  (15,0)  IHIT  (") 
.DO("CAXX  a00T(XABEXsfr")  .OOT  (■);") 

.OOT  ("DECLARE  aSTOEAG(0:  ") 


.DO("CAXX  80tT(XABPtS)  ;")  .OOTf")  CPABACTEtfS)  EZtEBfAL;") 
.OOT  ("TIHCXODE  PXAHS  (0BJDCX1)  ;") 

.OOT  ("2  aBIHART_HODES(0r  ")  .DO  ("CALL  BOOT  (tOBES)  ;■) 

.OOT  (»)  ,r","3  asOH  fixed  BIHAPT  (15,0)  IHIT(0),«") 

.OOT("3  SBPOTEEB  fixed  BIHAET  (15,0)  HIT(O),*") 

.00T("3  aiABEX  FIXED  BIHAET  (15,0)  IHIT(O);") 

.OOT  ("HIHCXODF  FXAHS  (0B3DCX2)  ;")  ) 

SFBI_COXOH 

*(  "DECXARE"  DECXAEE_STATFBEHT  ) 

.OOT  (») 

( .TFST(TAKE_STATISTICS_FXAG  = 0) 

.OOT("POT  FIXF  (STATIST)  EDIT  (•  **0*  •)  (A)  ;=•) 

I .EBPTT  ) 

t PBOGPAB_OB1T 

ODTPOT_DFCXARATIOHS 

"EHD"  ( .ID  I .FBPTT  ) SFBl  COXOH 

.OOT  ("aPFOC_EXIT ; ;") 

PEDHE_LOCAL_TPFES 

.TFST(HOBBAX_BFHGF_SHITCB  = 1)  .FRR  (2) 

.DO ("CAXI  eTHCXODE~PEOCFDOEES;") 

.DO  ("CAXX  aiHCXDDE TpFCXAE  ATIOHS  ;“) 

( .TEST(TAKF_STATISTICS_FXAG  = 1) 

.ODT("*IHCXODE  PXAHS  (OB  JBEP)  ;") 

I .FBPTT  ) 

.OOT  ("EHD;") 

.PEEK{"r^iei£")  ; 

OPTIOH^FLEBFHT  := 

"HAIR" 
r "EITFBHAX" 

.SFT(BAIH_FXTEEHAX_SBITCB  = 2) 

I "ROTES" 
r "HOHOTFS" 

.SFT  (OPTPIIT_HOTES  FXAG  = 0) 

I "HOTPACE" 

.SET  (TPACE_FXAG  = 0) 
t "TRACE" 

.SET(TRACE_FIAG  = 1) 

I "STAT" 

.SET  (TAKF_STATIST1CS_FXAG  = 1) 
t "HOSTAT" 

.SET  (TAKE_STATISTICS_FXAG  = 0) 

( "BODES" 

( "("  ( .EBPTT  ) 

.HOB  .DO("HODFS  = 8STHB0X; ") 

$ "," 

.HOB  .DO("XABEXS  = aSTHBOX  + BOD  (8STHBOX ,0)  + 3;") 

")  " .SET  (DrFADLT_HODFS_FXAG  = 0)  ; 

OOTPDT_DECXABATIOHS  := 

.FBPTT 
.IHIT_BXOCK 
.FIHD~HEXT  (1,1,  "P") 

( .TABXFjrEST(2,1,"B")  .SET(EECDBS1TE_FLAG  = 1) 
t .EBPTT  .SET(PFCORSIVF_FXAG  = 0)  ) 

.IHIT  BXOCR  ' 

*(  .FfHD_HFXT(1,1,"B") 

.OOT  ("DECXARE  ",**,"3  FOIITFR  STATIC;") 

.OOT  ("DECXARE  «,**,"S  FIXED  BIHAET  (15,0)  ") 
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.00T("B1SED  (■,**,"9);")  ) 

.imT_BLOCK 

*{  .PIIIDJtEXT»1,1,"T") 

.ODT  {"DECI.1EE  FIXED  BIJXEl  (15,0)") 

.(  .TXBLE  TFST(2,1  ,"PF) 

) ST1TIc3iF_F0T_BEC0ESI»F  .00T("  lEIT(O)")  ) 

.OBT(";»r  )~ 

-INIT_B10CK 

I(  .FIED  BEXT  (1.1,"*") 

-ODT  ("DECLXRE  FIXED  BIIIXHI  (15,0)") 

STlTlCjrF_B0T_KFC1JBSIVE 

.ODT(";")  ) 

.I«TT_B10CK 

$(  .FII»D_1IEXT  (1,1,"F") 

.DO("IF  lBDEt(»IJKEBll’,SHBSTE  (aSTH_lIXBF(asiHBOL_LEVBL,") 
.DO("aslBEOt_»nBBEE)  ,1,1)  ) = 0 ") 

.DO("TFEB  SDBSTE  (aXSSJIFO  (asTHBOI._lFTFt,aSTBBOL_«DBBFE)  ,1,1)") 
.D0("=  'E';") 

.0DT("DFCL1EE  ",»*) 

( .TiBLF_TFST(1,1,"E")  -OUT  |"  DECIBAE  FLOIT  (6)") 

I .EBPTT  ,00T("  FIXED  ElEXEl  (15,0)")  ) 

( .T1BLE_TFST(2,1,"P") 

I st»tic_if_bot_efcdesifF  ) 

-OBT  (";■))  ~ ; 

STRTIC_IF_FOT_BECDFSIYF  := 

.TEST(PECnPSITE_FEXG  = 0) 

,OOT("  STATIC") 

I .EBPTT  ; 

PBOGPAB_OBIT 

* ( .LABEL 

( .PEEK  ("PBOCEDOEE") 
r .EBPTT  .OOT("t")  ) 

.ODT(*)  ) 

.SET  (TEACE_ALEFADTJ30TPDT_FLAG  = 0) 

( .PEEK  ("PHD")  .BEG  .EETDFH 
I PP0CEDDPF_BL0CK 
I STATEBEKT  ) ; 

P EOCFDOBE_BLOCK  : = 

.PEEK  ("PEOCEDDEE") 

.DO(»aSTBBOL  = SDBSTE  (aSTEBOL,1,LE»GTP  (aSTBBOL)  - 1);") 
.SFAECF_ALL  .IF_KFB  (1,2,"PD") 

.TABIE_TEST(1,1,"P">  .EEE  (3) 

.FKTFE  (1,2, "PD") 

"PPOCEDOBE"  .ODT(*) 

.BLKEBTEE 

.SrABCF_BLOCr  .EHTFE(1,2,"PD") 

( "("  S","  .ODT(*) 

PBOCEDOBE_AEGDBEKT 

J(  I","  .ODT(",")  PFOCEDDEF_APGDEFHT  ) 

")»  .ODT(") 

I .EBPTT  ) 

( "EFCDESITE"  .ODT("  EFCDPSIVE") 

.IBIT_BLCCK  ,FIKD_FF.XT  (1,1,"P")  .EKTFP  (2,1,"P") 

I .EBPTT  ) 

.ODT  (";") 

.DO("BLFTEL  = 8LFVEL  + 1;") 


TRACF_ODTPDT 

.SET  (STATISTICS  SBITCP  = 1) 

TAKE_STAT1STICS~ 

SPBI_COLO» 

S(  "DECLARE"  DECLAEE_STATEBEBt  ) 

S PBOGBAB  OBIT 
ODTPOT_DFCLABATIOBS 
"EBD"  ~ 

TB4CE_OOTPOT 
.OOT("aPROC_EXIT:  ;") 

PROBE  LOCAL  TREES 
( .TD~|  .EBPTT  ) 

.DO("aLFTEL  = aiETFL  - 1;") 

SEBI_COLOB  . ODT ("EB  D ; ■) 

.BLKEXIT  ; 

PEOCEDDEE_AEGDHEBT  := 

.TREE  .OOT(*) 

.SEARCF_ELOCK  .IF_BFB (1,2,"TP") 

I .ID  .ODT(*) 

.SFAPCF_BLOCK  .IF_BFB (1,2,"TP")  ; 

DECLAEE_STATEBEBT  := 

.SFT  (STATISTICS_S»ITCF  =11) 

TAKF_STiTTSTICS 

t "," 

rECLARF_ITFB 

*(","  S","  DFCLABF_ITFB  ) 

"LOCAL"  ~ 

SEBI_COLOB  ; 

DECLAEE_ITEB  := 

.PEEK  ("LOCAL") 

I .TFEE 

.SFAPCF  BLOCK  .IF  BFB  (1,2,"$D") 

I .ID  ~ 

.SEAFCF_BLOCK  .ir_BE» (1,2,"TD")  ; 

PEDBE_LOCAL  TREES  := 

.TEST(FAIB_FXTFBHAL_S»IICE  = 2) 

.DO  ("BLOCK_LF»FL_CODBT  = aBLK_LFTFL_CBT;") 

( .TEST  (ELOCK_LiVEL_CODBT  = 1) 

.IBIT_BLOCK  ~ 

S(  .PIBD_BEXT(1,1,"T") 

( . TABLE_TEST  (2,  1 , "P") 

I .EBPTT 

.0DT("aS0FT  LIBK  ADDB  = ADDR  (",••,")  ;") 

.ODT  ("CALL  iPBDBE;")  .SEARCH_PPOCEDDBE  ("aPEDBE")  ) ) 
I PPOKE_DFCLAPFD_TPFES  ) 

1 PBOBE_DECLARED_TPEES  ; 

PBDBE_DECLAPED_TBEES  r= 

-FBPTT 
.IBIT  BLOCK 

*(  .FIBD_BEXT(1,2,"TD") 

.OOT("aSOFT  LIBK  ADDP  = ADDP  (",•*,")  :") 

.OOT("CALL  aPRDBF;")  .SEARCF_PBOCBDDPF  ("aPFDBF")  ) ; 
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^««*«*»*»»** •******•/ 

/*  STATEHEST  IIEES  ♦/ 

yf********»*»»*******/ 


STITEHEBT  := 

.S«IK_OSE(SOFT*01,S0E*01,STE*01) 

.BESET  (SOET*0 1 ,HDB*0 1 , STE*01) 

TEICE  OOTPOT 

.SET  IAS  GF_T»_GB1E_PE_IF_0THE_S»ITCB=7) 

{ COEDITIOFAL_STATFHPBT 

I 0»C0FDITT0«AX_STATEHE»T  SEBI_COEOF  ) 

.BESET  <SOFT*0-»,»1)B*01,STB»01)  : 

DSCOBDITIOIIAIJSTATEKEFT  : = 

.PFEK<"ETO")  -EEG  .PETOBB 
t .PEEKf";")  .OBT(";") 

I "STOP" 

.SET  (STATIST1CS_S«TCH  = 14) 

TAKE_STATISTICS 

( .TEST  (TAKE_STATISTICS_E1AG  = 1) 

.OOT  ("GO  TO  aEIIT;  ") 

I .EBP.TT 

•OOT  ("BETOEP;")  ) 

1 "PETOEH" 

.SET  (S TATI STICS_SPITCF  = 1!>) 

TAKE_STATISTICS 

.OOT  ("GO  TO  aPPOC_ETIT:") 

I "TP ACE" 

.SET  (STATISTICS_S»ITCE  = 26) 

TAKE_STATISTICS 
( .TEST(TKACE_E1AG  = 1) 

.OOT  ("aTEACE  = ") 

( "BTGF"  .OUT  ("2;") 

( "LOB"  .OOT("1;") 

} "OEE"  .OOT("0;")  ) 

I -ID  ) 

I "BEGIW"  BEGIRJBLOCK 
I "DO"  BO  GBODP 

I "GO"  ( ^O"  I .EHPTI  ) -IB 
.SET  (STATISTICS_SB1TCF  = 12) 

TAKE  STATISTICS 
.odt7"go  TO 

) "CALL"  CALL_STATEEE»T 
I TBEE  ASSI6BBEIIT  STATEBEBT 
I "LABEL"  LABELJkSSIGBBElT^STATFEEBT 
) "PBOKE"  'PB0KE_STATEHEBT 
I "GPAET"  GBAEtIsTATEHEBT 

1 "IBSEPT"  .SET(IHSEETJEEAFT1BSEBT_SB1TCE  = 1) 
.SPT(STAT1STICS_SB1TCE  = 19) 

TAKE_STATlSTlCS 
IBSEPT_STATEBE1IT 
I "ABTAKCE"  adtafce_statebeit 
I IBPOT  onTPDT_STATEBE*T 
I "DEFIBE"  DEEIBE_STATFBEBT 
) "OBBFE*  OPBEE_STATFBEBT 
I AEITHBETIC_ASSIGBBEBT_STATEBEBT  ; 
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/*  BFGIB  BLOCK  »/ 


BFGIB_BL0CK  r= 

BLKEBTEP 

IsFAPCF_BLOCK  .TF_BEB  (1,2,"PD") 
SEEI_COLO» 

.OOT  ("BEGIH;") 

.SET  (STATISTTCS_SBITCF  = 2) 
TAKE_STATISTICS~ 

J(  "DFCLAEF"  DFCLAEE_STAIFEEBT  ) 
t PBOGPAB_DBIT 
ODTPOT_DECLAPATIO»S 

"EBB" 

TEACE_ODTPnT 

.DO("BLFTEL  = BLEVEL  - 1;") 

.OOT  ("EBB;") 

.BLKEITT  ; 


/»•»•»•*•••••/ 

/*  DO  GBOOP  •/ 

^**« ••«•*«*•*/ 

DO  GBODP  := 

~ "WFILE"  DO_BFTLF  GBODP 
) "FOP"  "ALL"  “ 

( "SDBBODES"  BO_SDBBODE_GBODP 
I "COBBIBATIOBS"  DO_COBB1BATIO!I_GPOOP 
t "PEBBOTATIOFS"  DO_PEBBOTATIOK_GPODP  ) 
r DO_IFCBEBEFT  GBODP 
I .sft(statistTcs_switcf  = 3) 

TAKE_STATIST1CS 
.OOT  ("DO;") 

DO_BODl  TPPOOGF_FFB 
.ODT{«FBD:")  ; 

DO_SOBFODE_GBOOP  r= 

;SFIE_OSE(SOET*01)  .RESET  (SOET*01) 

"OF"  “ 

.SET  (STATISTICS_Sf  ITCF  = 6) 

TAKB_STA TI STICS" 

SOFT_TEEE_FOEE 
"OSIFG"  ~ 

BASED_TPPEjlABP 
.EBTEB  (3,i7"A") 

.OOT(*,"8  = ABDB(aSOB(",SOET»01,"));") 

.OOT  ("DO  WEILF  (",*,"*  > 0);") 

.SAT{*) 

.CAT("»  = ADDF(9BR0TEPP  (",•,"*))  ;“) 

.BESET  (SOET»01) 

DO_BODT_THBODGP_EFD 

.DO  ("DO  ai=»BLK  STEBOL_CBT  (aBLK_LETEL_CFT)  TO  1 BI  -1C") 
.D0("»EILE(SDBSTR(aASSJlFF0(aBLK_LFTEL_CFT,ai),3,1)  -»=  *A*)  ;") 
.DO("EFD;")  ^ 

.D0("SDBSTB(»ASS_IFF0(aBLK_LE»EL_CBT,ai),3,1)  = • •;") 
.ODT(f,"EFD:")  ; 

DO  IFCBEBEFT  GBODP  r= 


.S»IE_BSE(LAB*01,1IOH*01) 

.BESET  JI.1B  *0 1 
.ID 

.sat  ("") 

( .TEST  (TRICE  ELiG  = 1) 

•CiT("IF  BTRICE  > 1 TBBB  ROT  EDIT  (••TBlCEr  VIEIIBLE 
.C*T(*,"  - •»,«,*,»)  (COI  (70)  , »,C01  (77), i,E  (13, 6));-) 

I .EBPTI  ). 

.SET  (STiTISTICS_SSITCP  = 4) 

TiKE_STiTI STICS” 

.OBT  ("DO  ■,»,■=■) 

•SET  (TPEE_STBIfG_lPITF_SBlTCE  = 3) 

■=« 

C01STRiIlED_EIPBESSI0> 

S(  -0DT(»)  COBSTEIIIIFD  EXRRESSIOI  ) 

( "TO"  .ODT("  TO  ■)  “ 

C0IISTBAIIIED_EIPFESSI01I 
( "BI"  .OOT(«  BY  ") 

COIISTEIT«ED_EIPRESSIOE 
I -EBPTI  J ~ 

*(  .OOT(*)  C0»STEIlIBED_EIPPESS10ir  ) 

. t .EBPTI  ) 

.ODT(";") 

( "B'BILE"  ■ (■  .ODT("IE  ■) 

B00LE»»_EIPBlSS10f 

“)"  .OOT("  THEB;  ELSE  GO  TO  ".lEBTOI,";") 

.RESET  (BOB  *01) 

.ODT  (•) 

DO_BODT  TFBODGH  FED 
(.ID  .EHPTir 
.OOT(»EIID;") 

.LEB(L1B*01) 

( .TEST (TRICE  ELIG  = 1) 

( -EBPTI  .OOt7";")  ) 

-RESET  (LiB*02) 

I .OOT(») 

-RESET  (B0H*01) 

DO_BODT_TEBOltGH  FID 
-OOT("E»D;»)  )~  ; 

DO_COEBIBATTOB  GROOP  r= 

.siip_dse7lib*02) 

-SET  (STATISTICS  SBITCE  = 7) 

TAKE  statistics" 

( ,"OE«  I .EBPTI  ) 

SOET_TBEE_»ODE 

"TAKER" 

.ODT("aCOHBI»AT10«  SI2E=") 

AR1TH_EIPB1SSI0B  ~ 

"AT" 

( "A"  r .EBPTI  ) 

( "TIBE"  i -EBPTI  ) 

-OBTr;"»"lE  »EIRST_COHBH  (",SOPT*01,")  TPEB  GO  TO  ",LAB"02,";") 
.LAE  (LAB  *01) 

.RESET  (SOFT*  01) 

DO_BODI_THROOGB_FHB 

.ODT("IE  aKEXT_COBBI»  THEB  GO  TO  ",LAB*01,»;") 

.LAB  (LAB*02)  ToOT  (" ; ") 

.SEAECH_PPOCEDORE("aCOBBIB")  ; 


DO_PEFBDTATIOB_GEODP  := 

.SBIR_DSE (LAB*02) 

-SET  (STATISTICS_SBITCR  = 8) 

TAKERS  T A TI S T ICs" 

( "OF"  ( .EBPTI  ) 

SOET_TPEE_FODE 

"TAKER" 

.OOT("aCOBBIHATTOR  SIZF=") 

AP.ITH_EXPRESSIOR 

"AT" 

( "A"  I .EBPTI  ) 

( "TIBE"  I .EBPTI  ) 

.ODT(";","IE  aEIBST_PFRBnT(",SOFT*01,")  TPEB  GO  TO  ",LAB*02," 
.LAB  (LAB*0 1) 

•RESET  (SOFT*01) 

DO_BODI_TEBOOGB  EBD 

.001  ("IP  aBEXT_PEBBDT  TPEB  GO  TO  ",LAB*01,";") 

.LAB(LAB*02)  .00T(";") 

.SEARCF_PBOCEDOPE  ("BCOBEIR") 

.SEAECB_PFOCEDOBB ("8PEFBDT")  ; 

DO_BFILE_GRODP  t= 

.SBIE  DSE(IAB*02,SOFT*01,BOB"01,STR*01) 

.RESET  (S0ET*0 1 .ROB *0  1 , STB *0 1) 

.SET  (STATISTICS_SBITCF  = 5) 

TAKE_STATTS51CS 
.LAB  (LAB»01) 

( "(■  I -EBPTI  ) -ODT  ("IF  ■) 

BOOLEA  R_EXPR  ESSIOR 

")"  -ODT("  TFEB;  ELSE  GO  TO  ",LAB»02,"J") 

-E  FSFT  (SOFT*0 1 ,B0B  *0 1 , STB *0 1) 

DO  BODY  TFROOGF  ERD 
.001  ("GO  TO  ",LAB*C1,";") 

-LAB(LAB»02)  .00T(";")  ; 

DO_EODI_TEHODGP_ERD  : = 

~ J)0("aiEST~=  BREST  ♦ 1;") 

SEBIjCOLOB 
t PROGEAB_OHIT 

"EBD"  " 

( .ID  I .EBPTI  ) 

TRACE  OOTPOT 

.D0("8REST  = aBEST  --  1;")  ; 


»»»****»»•*•»»»•••»***/ 
/»  CORDITIORAL  STATEBERT  */ 
/*•**••*•*•••••«•*«•••»•*•/ 

C0RD1TI0RAL_STATEBERT  := 

.SRIF_OSF (SOET*0 1,B0B*01, STR*0 1) 

-RESET  (SOET*01,ROB*01,STR*01) 

"IE" 

-SET  (STATISTICS  SBITCE  = 9) 

TAKE_STATISTICS” 

-OOT("IF  ") 

BOOLEAB_EXPPESSIOR 
.DO("asTBT  = aSTBT  + 1;") 


Fig 
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■—  • 1*.1>  I .ebeti  ) 

® "TBEB-  .ontr  THEE  DO;") 

.BESET  (SOET*01  rEDH*01»STH"01) 

.SSrrEE^'DO;-)  STITEHEHT  .OOT(-EBD;") 

I .EBPTl  ) ; 

/•»♦*♦♦♦♦*•••♦•*•♦*/ 

/*  CilL  STITEHEIIT  •/ 

CILL  STMEHEBT  : = 

■".SBIH_nSS  CE»BD»0 1) 

•BESET  (H»BD*01) 

.SET  |ST1TIST1CS_S»ITCE  = 13) 

T»KE_STiTISTICS 

IsMBCF_M.l  .3E_BEi(1,2,»P0p 
.T»BLE_TFST  (1,1,"P")  .EBB  |3) 

.OOT("CltE  ",*) 

( "(F  .OBT(») 

CML  IBGDHEBT  

.DOT  (•)  ClEL_iBGDHEBT  ) 

,ODT(») 

I .EHETY  ) 

.ODT  ("  ;") 

.beset  (hipd*01)  ; 

CALL  ABGDHEBT  := 

~.SIIIE_l)SE(EABD"01) 

'.DOrBOBHAxlHEBGE.SBlTCE  = B0BB1X_HEBGE_S«ITCB  + 1;") 

!oDT'pAED*On"a  = ®^““-^^*^n»SAx’i!EEGE  SBITCB  - 1-") 

.00(«BOEHAX_HEBGE_SHITCH  = «0BB1I._BEEGE_SBITCB  1,  } 
,OBT  (FABD»01,"*") 

J InorBOBHAt  HEBGE_SflITCB  = BOEBAl  HEEGE_S«ITCB  - I*,") 

.SET  <TEEE_STBIliG_ABITP_SBITCE  = 3) 
C0BSTE1I1ED_EIEPESSI0B  ; 


/*  obdeb  stateheht  ♦/ 

OBDEB  STATEBEBT  5=  ’ 

.S»IB_DSE  (SOET*01,LAB*01) 

.BESET  (S0ET*01) 

.DO("aSOET_EOSITIOir  = 3;") 

.SAT  <"CAEL  ELTSBTD  (•  * S08T  FIELDS-  ( ) 
SOETJTPEE^HODE 

OOT("aTEHE  BDDB  = ADDE  (BSOB  ("  »SOPT*01,")  ) . ) 

.odtisoet*oT,»  = asoi(-,soFT*oi,");") 

.OOT  ("PEOCEDOBE  BETOBBS  (CHAB  (S5)  ) ;") 

IoDT("XF  ",SOFT*01,"  <=  0 «") 
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.OOT("TBEB  bo;  call  ELIBETCfB);  BETDHB  (aSOBT_DATA)  ; EBD;  ) 
.OOT  ("ELSE  CALL  PLIBFTC  (12)  ;") 

.OOT("SSOFT_TEBP  = ■ ,S0FT*01,";") 

.OOTC"OBSEEC(SSOBT_CPkB)  = ^ 

.OOT  ("SOBSTB  {SS0BT_DATA,1.2)  - aSOET_CHAB,  ) 

.BES^r  (SOTT*01) 

OBDEB  ABGDBEBT 

*i‘'!pFSET(SOFTioi)  .CAT(«,»)  OBDEP_ABGOBEBT  ) 

.ODT(SOFT*C1,"  = BBBOTBEB  (»SOBT_TEBP)  :•) 
loDT  ("BETOBB  (8S0BTJ)ATA)  ;") 

OOT  ("EBD;  ") 

"oOT(l."l  BECOBD  TIPE=F,LEBGTE=(95>") 

"oOT("  • >,20000, asOBT_EFTDEB_CODE, ",LAB*01, ",asO«T_OOT)  . ) 

Iseaecf_peocedobe("bsoeoot")  ; 


obdeb_abgobebt  ;= 


.SBIE_OSE(SOET*01) 

.BESET  (SOET*01)  ..... 

I «_«  .D0("aS0ET_DTBECT10B  = *A’;") 

I .EHETI  .DO  ("BSOBT_D1BECTIOB  = ‘D';")  ) 

( ■TELEBEBT"  t .SET(PEEIOD_ALBEADT_FOOBD_FLAG  - 1) 

SOFT  0OALI?IFR_BT_LABEL  ) ' 

BESET  fSOFT*01)  SOFT  00 ALIFIEF_BT  LABEL 

I beIet  roft"01  soft  OOALIFIEE_BI_SOBSCBIPT)  

'o^TC-aLpf  ?EBP  BOB  =-aGET_TAL0F_STBIBG(-,S0ET(01,")  ;") 

bit  ,.To.T.TOTmo«-, 

.DO("  (F(10))  ;") 


•JS  FS55t“5?ok'i_IE«T_ST.1»6  .TTMII  PS0«I_IM»_SIW1I1!  ')  ) I 

.DO{"(F(10)>  ;") 


:SS(-sSbstm8so‘^Uebp_steibg,tebift  (8S0ET_TFBP_STRIBG,.  •») 
.CAT(".10,PL,") 


.DO  ("CALL  aCAT(asOBT_DIBECTIOB)  ;")  . 

.DO ("asOET_POSITIOB  = asOBT_POSITIOB  + 10 ; ) , 


;") 


;■) 


^ IEEE  ASSIGBBEBT  STATEBEBT^V 

tbee_asstgbbebt_statehebt  j= 
fabd_tbee_hodf 

.SET  (AS  gr_ib_geib_pb._if_otee_sbitcf=1) 

.SET  (SET_SOET_LIBK_FLAG  = 0) 

.SET  (TBEE  STBIBG_ABITF_SV1TCE  = 1) 
C0BSTEAIB2D_EI?EESS10B 
.SET  (SFT_SOFT_XIBK_FLAG  1) 

SFT  LABEL_BEPLACE_FLAG 
( .TEST  (BEAL  DOBHT_S«ITCB  = 1) 


ORIGINAL  PAGE  IS’ 
OP  POOR  QUALiry 


t .ERPTT 

.0DT("C»1X  SGEiFT;") 

• SE4ECI!_PPOCrDDEr<"8GKiF3'»)  .SE*PCB_PEOCPDnpF  ("aPEOKE")  ) 
.SPT(STATISTICS_S»ITCE  = 16) 

T*KE  STATISTICS  ; 


^«*»*«**»»#«***«*******««**»**/ 

/*  LBBEI  ASSIGBHUT"  STATEHEKT  »/ 


AEEL_ASSIGKEE«T_STATEHEBT  := 

.SET{ETATIST1CS_SBITCP  = 17) 

TAKE  STATISTICS 
" (■  ^FAED_TEEE_HODE  ") " *•=" 

.OPT  ("CALL  aPFSEPTFC") 

,SFT  (TEEE_STEHG_AEITB_SHITCH  = 2) 

COPSTEATKED  EIPPESSIOP 
.OPT  (",8LABiL  (SHAPE_LI»K)  ) ; ■) 

( .TEST(TPACB_FLAG  = 1) 

.OPT  ("IF  a TP  ACE  > 1 TEES  CALL  fflSODE_TEACE  (aPABD_LIBK)  ; ") 
I .EHPTI  ) ; 


y***^m**************/ 

/*  PBDHF  STITEHFKT  ♦/ 

/♦♦♦♦♦♦♦♦»♦*♦♦♦♦♦♦♦»/ 

PROHB_STATFI?P»T  S= 

.SSIE_PSF(SOFT*01)  .HFSET(SOFT*01) 

•SET  (STATISTICS_SH1TCH  = 18) 

TAKEJSTATISTICS 

. S FT  (A  S_GH_IS_GEIS_PE_IF_OTEE_S  «ITCH=5) 

•SET (SET_SOFT~LISK_FLAG  = 1) 

SOFT_TFFE  BODE 

.OPT("CALL  0PEPBF;")  .SEAECF_EBOCFDORE  ("aPEPBF") 
S(  .PESET(SOFT»01) 

"r" 

SOFT  TSFF_BODF 
.OPt7"CALL  aPEOBE;")  ) 

.SET(SET_S0FT_LIHK_FLAG  = 0)  ; 


/*♦»•*•**••***•»****/ 

/»  GPAFT  STATEBEBT  •/ 

i /♦♦»»**»**»**»»»»*•*/ 

i GPAFT  STATEBEBT  t= 

i 7sFT  (SrT_SOFT_LIBK_ELAG  = 1) 

( »IBSEET"  -SET  (IBSEET_GEAFTIBSEET_S»ITCF=  2) 
.SET  (STATISI1CS_S»ITCP  = 21) 

? TAKE_STATISTICS 

i .SET  {SET_SOFT_LIBK_FEAG  = 1) 

IBSEET_STATFBFBT 
.SFT(SET_SOFT  LIBK  FLAG  = 0) 

I .SET (TPEE_STPIRG_AEITE_SSITCB  = 1) 

.SET  (STATISTICS_SWITCH  = 20) 

'f  TAKE_STATISTICS 

i .SET  (SET_SOFT^LIBB_FLAG  = 1) 


>o 
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COBSTEAIBED_EXPEESSIOB 
.SET  (SFTJ50FT_LIB!f_FLAG  = 0) 

"AT" 

EAED_TEEE_BODE 

SPT_LABEL_PEPLACF_FLAG 

.OPT  ("CALL  3GBAFT:")  .SFAPCP  PPOCFEPBB  ("acPAFT") 

.SEAECH~PEOCFDOEF  ("aPPOBF")  ) ; 


/**••«••*•**•»**•**•«/ 

/*  IBSFPT  STATFBFBT  */ 

/***•«***•*•»*•**•**•/ 

IBSFBT_STATPBFBT  := 

.SBIE_PSE(SOFT*01) 

.BESET  (SOFT*01) 

.SET{TFEF_STFIFG_APITF_SBITCE  = 1) 

COBSTPAIBED_EIPEESSIOB 
( "BFFOPF"  I .FBPTI  ) 

.SET(POSSIBLE_BOOT_BODE_FLAG  = 0) 

EAED_TEEE_BODE  ~ 

.TEST  {POSSIBLF_EOpT_BOEE_FLAG  = 0)  .EBP  (5) 

.OPT  ("IF  asOB  {aHAED_LIBK)  -.=  0 I BLABFL  (aHAED_LtBK)  -.=  0 ■) 
.OPT{"TPEK  DO  ; aTFRP_SAYE  = aEAPD_LTBK;") 

.OPT("aFAED_LlBK  = 3BFB_E0DB;") 

.ODT("BBEOTEEE(aEAPD_LIBK)  = aTEBF_SAVE;") 

.OPT("FBD;") 

.ODT("aLAEEL_RFPLACF_FLA€  = 

( .TEST(IBSEET_GEAFTIBSEET_SBITCP  = 1) 

( -TFST(EFAL_rOBBI_SBITCF  = 1) 

.OPT("CALL  aCOPT7"rSOFT»01,")  ;■) 

.SFAECH_PEOCEDPEE  ("BCOPI")  .SEAECB_PBOCEDDPE  ("aPEPBE") 

I .EBPTI  , OPT  ("CALL  aGEAFTr") 

.SFAPCE_IEOCEDPPE  ("aCPAFT")  .SEABCF_PEOCFDPBF  ("SPEDBE")  ) 
( .EBPTT  .OPT  ("CALL  aCEAFT;") 

.SFABCH_PEOCFDPBF  ("acEAFT")  ^SEAPCH_PPOCFDPFF ("aPEOBF")  ) ; 


^«*«**»*«***»**4i*»***/ 

/*  ADTABCE  STATEBEBT  •/ 

/*«*•****««**•***••*«•/ 

ADTABCF_STATEBEBT  := 

•EBPTT 

.SET (STATISTICS_S»ITCH  = 56) 

TABE_STATISTICS 

BASED_TBFE_BABE 

.0PT(*,"8  = ADDE(aBEOTBEE  (■,»,"$))  ;")  ; 


/*•**•*•****«*•»••*•*•• *•**/ 

/•  IBPDT/OPTPPT  STATEBEBT  */ 

/♦♦*••*♦♦»♦»»»♦*••••♦••••**/ 

IBPPT_OOTPPT_STATEBEBT  := 

. SBIE_PSF  (SOFT*0 1) 

• RESET  (SOFT*01) 

■BEAD" 

.SET  (STATISTICS  SBITCE  = 23) 


T1KE_ST»TISI1CS 
( "FILE" 

( "("  J .FBBTT  ) 

.ID  .onT("SIEPDT  = 
a)  n 

l'  PBPTI  .OOTfV*  8I»B0T  = STSIE  */;")  ) 

I "COBPSESSED*  .SET  (1I0BB1L_C0BPBESSED_S1HTCB  - 2) 
f .EBPTT  .SFTJII0BB1L_C0BPEESSED_SWITCE  = 1)  ) 

S"," 

S{  IltPnT_ELEBEllT  J","  ) 

I "SBITF"  ” 

.SET  (STiTISTICS_SBITCE  = 24) 

TiBE  STITISTICS 
( "FILE" 

( "(»  ) .EBFTl  ) 

.ID  .OPT  f "SODTPDT  = 

f EBPTT  .OPT("/*  aODTPCT  = STSPBIBT  */;")  ) 

( "COBPBESSED"  .SET  {BOBHlL_COBPBESSED_SSITCH  - 2) 

I .FfiPTT  .SET  »BOBBiL_COBPPESSED_SWITCH  = T)  ) 

$(  ODTPDT_ELEBEIIT  *",").  ? 

IlfPDT_ELEREPT  ;= 

loOirGET  EDIT(".  *•  rt  Vf>T  11  H EI20  0))*") 

.onTfPBT  SKIP  EDIT(**IBPDT:*',",  »,  ")  (»,COH11)  ,E<20,0))  . ) 

I ElBD  TBEE_BODB 

I fIBPTT 

loDTrCBLL  aiKPDT_»ODE_COBPPESSED;") 

.SE1PCE_PP0CFD0KE ("aiBPSED")  ) 

.SEiECF_PBOCFDOSE  ("aPBDBE") 

.SFiPCP_W>OCEDnPE(“aODTODE")  ; 

OOTPOT_ELEBE«T  .:= 

^DOrBOPBlL^BEBGE.SSITCP  = BOEB»t_BEBGE_SBITCH  + 1;") 

OBTI"POT  skip  EDIT(**0DTPDI:**,") 

IdO("IIOPH»L_HEBGE_SBITCB  = »OEBiL_BEPGE_SBITCF  - lT  ) 

.ODT(“)  C4,COL(11)  ,E)  ;") 

* IoOT("POT  SKIP  EDIT(**OnTPCT;"',“,  *.  "MirCOt  <12)  ,E  (13,6)  ) ;") 
f .SET  (SET_SOET_LIKK_ELiG  = 0) 

SOFT  TEFE_!IODE 

( .TEST(IIOBBAL_COBPPESSED_SHITCH  = 1) 

.OOT  ("CIEL  aODTPBT_KODE(",SOFT*01,")  ; ) 

.SEAPCE_PEOCEDbBE ("ffiOOTODE") 

* *OOt”ciLL  aOOTPnT_KODE_COEPBFSSFD  |",SOFT*01,")  ;") 
IsElBCF_PPOCEDOBE("»OOTSED")  ) ; 


/*  DEFIBE  STiTEBEBT  ♦/ 

/****•**»•»♦*»♦*•••••/ 

DEFI»E_ST*TEBEBT  r= 
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.EBPTT 

BASED_TEEE_B»BE 

.Sk»(*) 

"AS" 

HABD_TEEE_KODE 

.ODT(f,"3  = aFAPD_LIKK_ADDB;")  ; 


ABITBBETIC_ASSIGHBE»T_STATEBEIIT  : = 

.ID  .ODT(*) 

.SAT("") 

* I^TPE"  ^“3;T  (••TFACEt  TABIABLE • • , • •") 

.CAT("r"  “ **,",",**)  (COL  (70)  ,A,COL  (77)  , A,E  (13,6)  ) ;") 

) .EHPTI  ) 

■=»  .OOT(*) 

.SET  (TFEE_STBI»G_AB1TE_SBITCE  = 3) 

C01ISTEAI1IED_FTPBESSIOK 

.ODT  (";",*) 

.SFT(STATIST1CS_S«ITCE  = 25) 

TAKE_STATISTICS  ; 


/•  GEBFEAL  EIPBESSIOBS  •/ 

CO»STKAHiED_ETPEESSIOB  ; = 

.S«IP_l)SE(SOFT*01,STK*O1,FOB*01) 

.PESFT  (SOFT*01,STB*0 1 ,BDB»01) 
.TEST(TFEE_STP3FG_AEITH_SB1TCE  = 1) 

( SOFTJIBEF  eODE 

( ebfk_pop_efitf_opffatob 

.BESET  (SOFT*02,BDB»01) 

.ODT(STP*01,"  = BGET_TAXOE_ABITH(",SOFT*01,")") 
AF ITE_EIPPESSIOK 

.OOT  r ;*) 

.BESET  (SOET»01,STE*01) 

.SET  (TBEE  STEIFG_AEITE_SSITCE=2) 
POT_TALDFjOF_DOBBT_FODE 
I .EBPTT  ) 

I .OOT(STB«01,"  = ") 

( STBTFG_FTPFESSIOF 

( PEEK_rOP_AFITB_OPEEAIOB 
APITE_EIPEESSIOB  ' 

I .EBPTT  ) 

I AFlTF_EXPPrSSlOF  ) 

.OOT  ("  ;") 

.BESET  (SOFT*01,STB*01) 

.SET  (IPEE_STFIHG_APITE_S»ITCF=2) 
POT_TALOE~OF_DOBBT_FODE  ) 

I .TEST(TEEE_STP1FG_AEITH_S«1TCF  = 2) 

( STBIFG  ETPFESSIOF 

( PFEK~EOB_lPITH_OPEBATOB 
ABITB_ETPPESSI0F 


I .BBPTI  ) 

I ,rO{"BORaiI._HERGE_SSITCB  = BORHIil_HERGE_S»ITCF  ♦ 1;*) 
SOFT_TREF  RODE 

.DO{"ROEHlt_HEBGE_SllITCE  = BOEniL_8EEGE_S«ITCF  - 1;") 
.OOT  ("BGET_»»LOE_STPIIIG  («,SOET*01,«)  «) 

.RESET  (SOPT»01) 

I .DO(»EOFalL_HERGE_SBITCR  = R0EHAL_HER6E_SBITCB  - 1;") 
1BITF_EXPPESSI0H  ) 

I *EITF_FXPFESSIOW  ; 


ailCOirSTRil!tFD_EXPRESSIOR  t= 

.SKIB  nSE(SOPT*01,RDB*01,STE*01)  .BESET ISOFT*01, 
.D0("»0RH1L  HER6E  SBITCP  = «OEB*L_HERGE_S«ITCE  ♦ 


■ OB*01,STR*01) 

1;-) 


SOFT_TFFE_BODE 
( PEEK  FOR  iElTF  OPFBATOB 

.ODt7bOB*01,"  = 8GET_ViLDE_lBITE  r»SOFT»01,")") 
iEITF_EIPRESSIO«  .OOTJ";") 

.PESFT(SOFT»01,STB*01, *08*02) 

I .ERPTI 

.SFT  {TRFF_STPI*G  ARITF_S*ITCE=1)  ) 

.DO("*OPBlt  BER6E  SBITCE  = *0EB11_BEEGE_SWITCE  - 1;") 


I STPIBG_FXPPESSIO» 

f PFPK  FOR  ARITE_OPFEITOR 

.DOf"*ORi»L_BEEGE_SiITCH  = *ORBiL_BEEGE_S«ITCF  ♦ 1;") 

.DOT|*OB*017"  =") 

.BO|"*ORB»L_BFBGF_S*ITCE  = «OBBiI._BEBGE_S*ITCE  - 1;") 

IRITB  EXPRESSIO*  .OOT I";") 

.D0|"»0RE1L  RBBGF_SBITCP  = 10BBiL_BEPBF_S«ITCB  - 1;") 

.RESET  (SOFT»01,STR*01,*OB*02) 

I .EBPTl  .RESET  (S0FT*01,STB*02) 

.SET  |TPFE_SIEI*G_iRITP_SBITCB=2) 

.DO("*ORBiI._BBPGE_SBITCE  = B0RB11_BFEGF_S»1TCB  + 1;"> 

.00T(STE*017"  =“)~ 

.DOfBORBAI.  BERGE  SBITCR  = ■0RHIL_BERGF_SB1TCF  - 1;“)  .OOT)";") 

.D0(«B0EB»OeRGe7sBITCE  = ■0RB»1_BERGF_SBITCF  - 1;*)  ) 


I iEITH_FIPRESSIO*  .RESET(SOFT*01,STR*01, *08*02) 
.SET(TRBB_STEI*G_»PITE_SBITCE=3) 

.D0|"»0RB1I._BEFGE_SBITCB  = *OBBIE_BERGE_SBITCH  + !;■) 
.OOT|*OH*01,"  =")~ 

.DO("*OEBlt_BERGE_SBITCF  = »0EB1L_BPBGE_SB1TCF  - 1;*)  .OOTf";«) 

.D0("*0RBAL~BEPGe7sBITCB  = *ORB»X_BEBGE_SBITCB  - 1;")  ; 


/*•»«»•*••*••*•«*******/ 

/*  BOOIEA*  EXPRESSlb*  */ 


BOOXE»B_BXPEESSIO«  r= 

BOOLEA*  TEPB 

*(  "I"  ~.OOTt*)  BOOIEA*_TFEB  ) ; 


BOOIEA*_TEEB  r= 

boolfaf_ebib  art 
* ( *G"  .OOT  (*) 


BOOIEA*_PE1BAET  ) ; 


BOOtEAB  PEI BEET  := 

.S«TK_OSE(SOFT*02,BDB*02,STE*02) 


.RESET  (SOFT*01, *08*01, STE*01) 

"(■  .OOT{*) 

SOOIFA*_FXPP ESSIO* 

")  » .OOT{*) 

I .00T{*)  E001EA*_EIPF  ESSIO* 

) OHCO»STP1IBFD_FXPEFSSIO* 

{ ( ■=■  .SAF("") 

I .SAT  (•-•■)  ) 

( .TEST (TEFE__STRI*G_APITF_SBITCF=1) 
0»C0*STPAI*ED_PXPEESSI0B 
( .TEST  (TKEE_STR1*G_APITE_SBITCB=3) 

.OOT  r8GFT_VI10F  AEITH(*,SOFT*01,*)  ",*08*01) 

I .OOT  (♦  ,"8COBEAPe3tRI*G_OR_ARITF  (aGET_?A10F_STRI*G  (■) 
.OOT  (SOPT*01) 

( .TEST  (TEEF_STPI*G_APITF_SB1TCE=2) 

.OOT  (■)  ,«,STE*01,")  ■) 

I .FBPTT 

.OOT  f")  ,aGET_TArOE_STEIHG  {",SOFT*02,")  ) ")  ) ) 

) .TPST(TFEE_STRI*G^_*PITE_SB1TCF=2) 
D*CO*STRAIBED_EXPRESSIOB 
• ( .TPST(TEPE  STEIBG  AP1TF_SBITCB=3) 

.OOT (STR*01,» ,"="7*0B*01) 

I .OOT  t*  ,"eCOBPARE_STET*G_OR_lRlTB  {",STP*01) 

, ( .TEST|TREF_STPI*G_APITE_SBITCB=2) 

.OOT  (",",STE*02,")  ") 

I .EBPTl 

.OOT|",96PT_TA1,OE_STFI«G(",SOFT*01,"))«)  ) ) 
t .00T{»0B*01, »,"=") 

0*C0*STEAI*ED_EXPEESSI0* 

( .TEST (TFEE_STEI»G_ARITP_SBITCB=3) 

.OOT  (*08*02) 

I .TEST (TEEE_STEI*G_AE1TB_SBITCH=2) 

.OOT  (STB*01) 

I .E8FTT 

.OOT("aGET_TAIOE_ARTTB(»,SOFT*01,"5")  ) ) 

I ARITF  PEIATIO*  ~ 

{ .TFST(TBPF_STRI*G_AEITE_SBITCF  = 1) 

loDT  («BGETlTAXOE_ixEl»G  (■  , SOFT*0 1 ,")",* ) 
.SFT(TBFF_STP1«G_AFITB_SBITCE  = 3) 

CO*STB AIFED_EXPE ES SIO* 

I .TEST (TREE  STRI*6_AEITE_SBITCP  = 2) 

.OOT(STR*01,*) 

.SET  (TREF_STRI*G_APITP_SBITCE  = 3) 

COBSTRAIBED  EXPEESSIO* 

( .OOT  (*08*017#) 

CO*STEAI*ED_EXPEESSIO*  ) 

I ( .TEST(TEEE_STE1*G_AEITB_SBITCB  = 1) 

I .DO("*ORBAL_BEPGE_SBITCB  = *OPE*I_BFPGF_SBITCP  + 1j") 
.RESET  (SOFT»01) 

( .TEST(TBEE_STEI*G  AEITB_SBITCB=2)  .RESET  (STE*01) 

) .EBPTX  .EESFT'(*0B*0 1)  f 
POT_TAL0E_O*  DOBHI_*ODE 

.DO("*OEBAL  iERGE_S*ITCE  = *0EBAX_BEEGE_SB1TCF  - 1;")  ) 
.EESFT  (SOFT*01)  ~ 

( («,ii  I "*0T")  .00T("-^") 

I .EBPTX  ) 

TEFF_BEXATIO» 

.SET  (TEEE_STHI*G_AEITB_SB1TCP  = 1) 

.BESET  (SOFT*02)  ~ 


I 
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a-\ 


,D0("1I0EH»X_HEEGE_SMTCE  = «OEHiX_BEEGE_S*ITCF  ♦ 1;") 
^DO^OBaIlI^H6E_SSITCF  = »0EB»t_HEB6E_SWlTCH  - 1;")  ) ; 

->=- , »>. , ) 

-SET  (») 

I ••-.<=■•  .SET(«>") 

, .siv("<")  ; 

TBEE  PEtETIOB  r= 

.SIlB^nSE(SOFT*01) 

' "oS?racSBPlBFjKBTlciL-r’-SElBCH_PEOCEDnBP(-8COBEIDE^ 

' "oS?  r^GBPipf  SPBSET-r’  -SEEPCF_PEOCEDOEE  (-BCOBSET-) 

* .SE1BCP_PB0CFPDBF  (■9C0BPIDE") 

' "nnT"l-aCOBpiBE°EIEBE5T-)*'.SEl^  PEOCEDFBF  r»COBEBT-) 

.ODTraCOBPlEE.ELEBEBT  , sj^jj-fIpBOCEDFEE  (-aCOBPIDE-)  ) 

.OFT  («  ("  ,SOET*01 ,SOET*02,-)  ")  ; 


/*  TBEE  EXPFESSIOIIS  •/ 

FIED  TEEE_»ODE  := 

f { COBBI«4TIOB_SBESCElPT 

.OFTrcai't  8F1PD_SBBSCEIPT_C0BBIH;*; 

I FEEB0T1TI0B_SFBSCEIPT 

.OFT  rCAXL  aEAFD_SBBSCPIPT_PEBBFT;»)  ) 

.SET  lSTiTlSTICS_SHITCP  = 36) 

TBKE_ST1TISTICS 

I .TBEE  .SE4FCF_»1L  .1F_1IEB  {1 ,2,  TF  ■) 

( .TiBLE_TEST  (1»  .EFTEB  (1  r1  ) 

I .EBPTT  ) 

* loFT^IE^%*»"  = 0 TEEI  = aHEB_WODE;") 

•OFT  (*2BBBD_XIBK_BFP®  = SDBE  {■»*»")  ?") 

I .TABLEJEEST  (2,1,"P“) 

) .SET  (POSSIBLF_EOOT_BODE_ELAG  = 1) 

.EEPTl  ) 

I .TABLE  TESTO,1,"B") 

.TABLE_TEST  (3 , 1,"A")  .EBB  (4) 

.OFTraB»I>I>_m'K_ADDE  = -,*,"3;")  i 

.OFT  ("IF  aFABD_LI»K  = 0 THFB  aPABD_lI»K  = aHEF_»ODE,  ) ) ) 
.SET  (STATI3TICS_SSITCF  = 28) 

TAKE_STATISTTCS  -i, 

-SET  (ADDITTOllAL_00ALIFIEE_XEGAt_ELAG  - 1) 

.SET  (SFT_SOET_XIBK_FXAG  = 0) 

BHSBrCB%;T"’  .SFT(POSSIBXE_BOOT_BOPP_EXAG  = 
{ pfBDloFAXWIFBlBOABEX  .SET  (POSSIBLE_FOOT_FOBF_FXAG  = 0)  ) 

SOFT_TBEE_HODP  .BESET  (S0FT*01) 

' ™BTrCAXraSOFT5oBSCBIPT_COBBl»(".SOFT*01,“)  ?") 


Fig.  1.4-2  (cont) 


t PEEB0TATI01I_SFBSCBIPT  

.OFT  ("CALX  aSOFT_SBBSCEIET_PFBBFT(-,SOFT"01,")  ;■)  ) 

.SIT  (STATISTICS_SFITCF  = 29) 

TAKE_STATISTICS 
.SET (STATTSTICS_SS ITCH  = 44) 

TAKE_STATISTTCS 
.SETtFEAX_BFHBT_S»ITCE  = 1) 
f(  .BESET(SOFT*C1) 

SOFT_0F  AXIFIFB_BI_SFBSCF1PT 
I .BESFT(SOFT*01) 

SOFT_OniXIFIEH_ET_XAEEX  ) 

I (*"SnEBEHT"°^!.SEAFCF_AXX  .IF_HFB  (1,2,"BF") 

.SET  (EXEBEHT_PXA6  = 1) 

( .T ABXE_TEET (1,1, "B") 

I !tbee^”seaece^axx*'Iif_hes(1,2,-tf»)  .SET(EXEBFHT_FXAG  = 0)  ) 

( .TABXB_TFST(1,1,"*")  .EHTFP  (1, 1 ,"T") 
f .EBPTI  ) 

( .TAEXE_TFST(1,1,"B") 

( .TABXE_TFST(3,1,"A") 

.TFST(FXEHFHT_FLAG  = 0)  .EBB  (4) 

I .FBPTl  ) 

I .EBPTI  ) 

.SFT(STATTSTICS_SHITCP  = 29) 

TABE_STATISTTCS 
( .TABLE_TEST|1,1,"T") 

.OFT  (SOFT* 01,"  = *,*.";") 

( .TEST(SFT_SOFT_XTBK_FXAG  = 1) 

.OFT  ("aS0FT_XIHlC_AEDF  = ABDB  (",*,")  ;") 

I .EBPTI  ) ~ 

( .OFT  (SOFT*01,"  = 

( .TFST(SFT__S0FT_XIHK_FXAG  = 1) 

.OFT  ("aS0FT_XIHK_ABDP  = ",*,"8;") 

J .EBPTI  ) ) 

. .SFT{EFAX_DFP.B  f_SHITCF  = 1) 

( .TEST  (SET_SOFT_XI!IK_FXAG  = 1) 

$(  .SFT(SET_S0FT_X1HK_FXAG  = 1) 

.FESET(SOFT*01) 

SOET_OF  AXIFIEF_EI_SFBSCEIPT 
I .BESET  (SOFT*01) 

S0FT_0FAL1EIEB_BI_XABFX  ) 

I t(  .BESET  (SOFT*0 1) 

SOFT_00  AXTFIEF_EI_SOBSCKIPT 
( .BESET  (SO  FT*01) 

SOFT_OFAXIFIEP_BT_1ABFX  ) ) 

.BESET  (SOFT*02)  ; 


EABB_OOALIFIEB_BT_SFBSCBIPT  := 

.sfie_fse7hfh*oi,soft*oi) 

.BESET  (HBB*01,SOFT*01) 
n 

.SET  (XABEX_S0BSCBIPT_SHITCB  = 2) 

' ( "LAST"  ~ 

• SET  (STATISTICS^SB ITCH  = 34) 

TUTV  STATTSTTCS 

.0Ft7"CAXX  aFAEB_XAST:")  .SEABCH_PBOCEDFPE("aFABAST") 
I "BEIT" 

.SET (STATTSTICS_S1ITCP  = 35) 


TiKB  STATISTICS 

.SEkECE_PJtOCTDOEB  ("aHAPEXT") 

f FAED  FIPST_CPA1.I?IFE 
I .OOtl^aSOBSCFIPT  = ") 

ARITF  FXPBFSSIOB 

.OPT  (";","CA1.L  aPAPI)_SOB_lCCFSS;") 

•SET  (STAT1STICS_S»ITCF  = 36) 

TlirF_STATTSTICS 

. .SEAECE_PEOCPDnPP("aHlEPSS«)  ) 

.PrSFT|HCR*01,SOFT»01)  ; 


f 

ro 


FAED  FIRST  QBAllFlEP 
~.S»IF~nSP (1AB*01) 

.BPSFT  (LAB*01) 

"FIEST" 

.ODT  ("aSTOSCPlFT  = Ij") 

.OOT|"CALI.  BEAPD_SIJE_ACCPSS;“) 

-SEAECP  PBOCEDORE  ("aBABESS") 
.SET(I.ABEt_SDBSCKIPT_S1tITCF  = 2) 
.SET(STATISTICS_S»ITCB  = 32) 

TAKE_STATISTICS 
: "EIBST:'> 

.beset  »IAB*02) 

.OOT  ("SElEHEPTa  = ADBH  (aSOP  (aBAED_lI*K)  ) ; ") 
.ODirHO  PFllE  (lEIEBEPTf  > 0)  ;») 

•OUT  ("IE  ") 

BOOLEAP_EIPEESSTOB 

.OOT("  THEE  GO  TO  ",LAB»01,";") 

.OOT{“*EI.PHFlTa  = IDDF  (aBEOTHEB  (lEIEBPPTf))  ;") 
.OUT  ("FED;") 

.OOT("rFLEBEBTt  = aHEH_IODE;") 

.1AB(IAB*01) 

.OOT("aFAPD_ITPK_ADDB  = $E1EBE»T3;") 

.SFT  (STATTSTICS_SFI'>^‘^*'  = 33) 

TAKE_STAT1STICS  ; 

SOFT  QnALIFIEE_BI_SOBSCFIPT  r= 

.S»IH_nSF  (SOFT»0 1 ,m)H*01) 

.BESET  (SOFT»01,PBH*01) 

R |M 

( S0FT_FIEST_0DA1IFIEE 
I SOFT_ALE_ODAIIFIER 
I "EAST"  ~ 

SET  OP  SOFT. SOB 

.ODT(«DO  «FILE(3BEOTEEE  C",SOFT»01,")  -■=  0)  ;■) 

SOFT  IXFK_«FOTPFP 

.OOt1sOFT*01,"  = aBECTEFE(",S0FT»01,")  ;") 
.OOT("PRIl;") 

I .EFSFT(SOFT*02) 

.OBT("asDBSCBIPT  = ") 

( .TEST  (SFT_SOFT_LI!IK_FLAG=1) 

•SFT (SFT_SOFT_L1*K_FLAG=0) 

AP1TF_FXEBESSI0P 

.SET  (SET_SOFT_IISK_FLAG=1) 

I £FITF_rXPEESS10H  ) 

.C0T(";“) 

( .TEST  (SFT_SOFT_EIPK_FEAG-1) 

.ODT  ("CALL  aSSOBLK(",SOFT*01,")  ;") 


Fig.  1.4-2  (cont) 


.SrAPCP_PEOCFDDPF ("SSSDBLK") 

I .FBPTT 

.OOT("CALL  aSSDP  (",E0FT»C1,")  ;") 
.SEAPCF_PFOCFrOPF("aSSOB")  ) ) 

.EESET(BOR*01)  ; 

SOFT_riBST_f'DALIFIFB  : = 

.SIIIF._l!SE(SOPT*01,LAE»C1) 

.BESET  (SOFT»01,LAB*01) 

"FIPST" 

.SET  (STATISTICS^SBITCE  = 39) 

TAKE_STATISTICS 
SET_OP  SOFT_SOF 
.SET (STATISTICE_S*ITCF  = 00) 

TAKE_STATISTICS 
I "FIRST:" 

.SET  (STATISTICS_3»ITCF  = 00) 

TAKF_STATISTICS 
.RFSFT  (SOFT* 02, LAB *02) 

.OOT  ("lELEBEFTa  = ADDE  (aSOP  (",SOFT*01,")  ) ; ") 

( .TFST  (SET_SOFT_LIHir_FLAG  = 1) 

.OOT  {"aS0FT_LI*K_ADDP  = IFLFHFFia;") 

I jEBPTI  ) 

.OOT("DO  PFILF  (tPLELERT*  > 0);") 

.OOT  ("IF  ") 

( .TEST  (SET_SOFT_LIFK_FLAG  = 1) 

.SFT  (SFT_S0FT_L1»K_FLAG  = 0) 

BOOLFAF_EXPBESSIOP 

.SET  (SET_SOFT_LT!IK_FLAG  = 1) 

I BOOLFAK_riPFFSSIOK  ) 

.O0T-(”  TEEF  GO  TO  ",LAE*0 1 ,";") 

.OUT‘(1JteLEHEFTS  = IDDE  (aBFOTBEE  (fFLEHEFTF)  ) ;") 

( ,JFSTl(SET_SOFT_LIPK_FLAG  = 1) 

' -OOT:  ("aS0FT_LIWK_ADDF  = SELEBFRT3;") 

:ehpty  ) 

.boT  ("FBD;") 

.lab' (LAB  *01) 

■ tOOT  (SOFT*01  ,"  = IILEHEPTS;") 

.EFSET(SOFT*01)  ; 

SOFT_ALL_00ALIFIEK  : = 

.SHIP_DSF(SOFT*02) 

"ALL:" 

.SET  (STATIST1CS_SSITCF  = 02) 

' T A KE_S  TA TI ST ICS 
SFT  CP  SOFT_SOB 

( TtEST  {AE_GF._I»_GRIF_PR_1F_0TEB_SBITCF-1) 

.OOT  ("aTFHP_ADDF  = aPABE_LIIIK_APDP;") 

.OPT  ("I-FLEHEWTa  = ADDS  (",SOFT*C1,")  ;") 

OOT (SOFT*02,"  = aKER  RODE;") 

.ODT("aPAFD_LIHK_ABDP  = ABDB  (BSOH  ("  ,SOFT*02,")  ) ;") 
.OOT("aLABEL_REPLACE_FLAG  = »tT>*;") 

.OOT  ("DO  IPILEdELERFRTt  > 0);") 

.OOT  ("IF  ") 
b6olear_exppessior 
.OOT("  TFFH  DO;") 

.OCT ("aFAFD_LIRK  = aWFR_RODF;") 

.ODT("CALL  8C0PI(IELEBERT$)  ;") 


.SE»RCF_PSOCEDDEE  ("aCOPT")  .SElSCE_PEOCEDOEE  |"aPEHKE") 
.ODT("aHlBE_lIBK_lDDR  = M)DE  (aBEOTHEm8H»EB_lIllK)  ) ;■) 
.0DT("P1ID;") 

.0DT("JBLEHEIIT3  = iDDE  jaBKOTEEE  (JELEBEHTI)  ) ;") 

.001  ("BSD;") 

.0nT("8S0FT_IIBK_iDDP  = iDDP  (",SOFT*02,") 

.ODT  ("»PAED~1IkOi>DP  = aTEHP_»DDH 

• SPTIEPiL  DOHHT  SBITCH=2) 

I .TEST(iS_GE_I*_GBl»_fP_Ty_0tER_S«ITCE=5)  .BESET  (SOPT*02) 

• OUT  ("SE^EBEBTa  = i5ee7"»SOFT*01,")  ; 

.OOT("DO  »PILE|5ELEBE«X*  > 0)  ;«) 

.OOT(**IF  ") 

B0OEF»II_EXEPESSI01l 

•00T("  TBFH  DO;") 

.00T("3S0FT  tIBK  ADDS  = *EIFBFBT3;") 

.OOT("CAIE  aPSDBE;")  .SEAECP_PBOCEDOPE  ("aPEDirE") 
.OOTt"F«D;")  ~ 

.O0T("EtSE  JEIEBEBT3  = ADDE  (aBROTFEB  (SELFBEHT* ) ) ;■) 

.OOT  ("EBD;") 

I .EBPTT  .HESS1GE)"S;B0T  TFT  IBPLFBEBTED")  ) 

.BESET  (SOFT*01)  ; 

PAHD_OOAI.IFIFB_BI_LABEE  : = 

.SBIB  OSE(STE*01,SOFT*01) 

.EESET  (STH*0 1 , SOET*0 1) 

.SET  (LABEL  SOBSCHIIT_S«ITCH  = 1) 

.OOT  (■aLAEiL_STEIBG  = ") 

( .XD  .OOT 

.SET  (STATISTICS_SWITCE  = 30) 

I mDlBECT_CFAE_STFIBG  -00T(";"> 

.SET (STATTSTICS_SVITCP  = 31)  ) 

.OOT  ("CALL  aFAFD_LABEL;")  .SEABCB_PPOCEDDEF  ("aFAPBEL") 
.BESET  (STP*01,S0FT*C1)  ; 

SOET_0OALXEIEB_BT_LABEL  := 

-S«IE_DSE(SOET*02  , ETE*0 1) 

,B  ESFT  (SOET*0 1 , STB  *0 1) 

{"."  I .TBST(PEEIOD_lLEribT_FOO!tD_ELaG  = 1) 
.SET(PEEIOD_ALPEADT_FOO«D_ELAG  = 0)  ) 

.OOT  ("aL ABEL  STEIKG  = ■) 

( .ID  .OOT("»*", *,"••") 

.SET  (STATISTICS_S»ITCE  = 37) 

I .BESET  (S0ET*02) 

•TEST (SET_SOET_LIiK_ELAG  = 1) 

1»DIFECT_CHAP_STFIBG 

.SET  (STATISTICS_SBITCE  = 38) 

.SET  (SET_S0ET_L1ER_ELAG  = 1) 

) ibdtf:fct_cfap~s’‘®i>® 

.SET  (STATXSTICS_SmTCP  = 38)  ) 

.OOT  {";") 

TAKE  STATISTICS 
( .TEST  {SET_SOFT_LIKK_FLAG=1) 

.OOT("CALL  asLAFLK(",SOET»01,")  ;") 

.SEAECF_PEOCEDOEE  ("SSLAELK") 

I .EBPTT 

,ODT("CALL  aSLlB(",SOFT*01,")  ;«) 

.EEIBCP_PBOCEDDEE  ("SSLAB")  ) 

.BESET  (SOFT*01,STE»01)  ; 


/»  STEIKG  PXFBESSIOKS  •/ 


STPI»G_EXPEESSIOK  := 

.STEIKG  .0DT{*) 

I "LABEL"  LABEL_STFIBG  ; 

LABEL_S1EIBG  := 

.SBIE_OSE(SOET"01)  .BESET  ISOET»01) 

.EBPTT 

.SET  (SET_SOET_LIKK_ELAG  = 0) 

.DO("BOBBAL_BFBGE_S»ITCE  = BOBBAL_BPBGE_SilTTCF  + 1;") 

"{«  SOFT_TEEE_BODB  ") " 

.DO("KOEHAL_BEEGE_SKITCE  = KOEBAL_BEBGE_SBITCP  - 1;") 
.OOT("aGFT_LABEL(",SOFT*01,")  ")  ; 

IKDIBECT_CFAE_STEIBG  : = 

.SKIE_DSF  (STF*0 1 . SOFI*0 1) 

.BESET  (STB*01,SOFT*01) 

nf  n 

.SET{SrT_SOFT_LIBK_FLAG  = 0) 

( "LABEL"  LABEL_STFIKG 

I 

( "LABEL"  LABEL_STEIKG  ") " 

) .EBPTT 

.DO("BOBBAL_BEEGE_SBITCF  = HOESAL_BEEGE_SBITCF  + 1;") 
SOFT_TPEE_BODE  "f" 

.DO ("BOB BAL_BEBGE_SBITCF  = KOPHAX_HPBGP_SBITCF  - 1 ;") 
.OOT("®GET_TALOE_STEIHG(",SOET"01,")"))  ) ; 


/•••***•••«***•*****«•••*•/ 

/•  AEITEHFTIC  EKPBESSIOK  */ 


AEITF  EXPEESSIOF  ;= 
rPITF_TEFB 

*(  ( I ) .00T(*)  AEITF_TEEB  ) ; 

AEITF_TFBE  :;= 

AEITE_EACTOE 

ff(  ( "/"  ) .O0T(»)  AE1TB_EACT0B  ) ; 

AHTE_F1CT0E  r = 

AEITH_PE1BABT 

( .OOT  (•)  AFITP_FACT0E  I .EBPTT  ) ; 

AEITF  PF.IBAET  := 

TsBIE_OSE(SOPT*01,BDB*01)  .beset  {SOP^*01,BDB*01) 
"IBEIKITT"  .OOT("1.F*71") 

I "BOBBEP" 

.DO("IOFRAL_BEFGE_SBITCF  = BOEHAL_REHGE_S*ITCP  + 1;") 
" ("  SOET_TPFE_BODE  ") " 

.OOT(BOB*01,"  = 0;") 

•OOT  (SOFT" 01,"  = asoB(",SOFT*01,")  ;") 

,ODT("DO  BEILE  (",SOET*01,"  > 0);") 


Fig.  1.4-2  (cont) 


.OOT(»OB*01,."  = "rSon»oi,"  ♦ 1;") 

.OUT  (SOFT* 01,"  = SBEOTEEE  (",SOFT*01,") 

OUT  f**Tin}*  **) 

lDO("HOEEiL_HFEGr_SSITCP  = irpEHIl_HFRGF_S»ITCF  - 1;") 

.ODT(!IOB*0ir 

.EFSFT  (SOFT*01,SDR*02) 

I "("  .COT{*) 

»E  TTF_F  JFE  ES  SIOF 
»)  " .ODT(*) 

I STEIFG_FIPEFSSlOB 
I .BOR  .OOT|*) 

I .ID  .OOT(*) 

I .TFST(FIBST_FEIBAEl_FODBD_FLiG  = 1) 

.SFT  (FTEST_PEIEiET_EOOBD_FLiG  = 0) 

I ( I »-■  ) .00  T(*) 

iFlTP_PEiniPI 

* .D0("H0PB4I._BFEGE_S»ITCF  = BOEE*L_EEEGE_SBITCP  + It") 
SOFT  TREE  BODE  _ 

.DO  ("BOEBiL_BEEGE  SBITCF  = BOF.H»l._BEEGE_SWITCF  - 1.  ) 
.001  (»aGET_V»L0P_»B3TH  {■,  SOFT*0 1 I 


/•*****»**********/ 

. /•  H1SCE1.L4IFODS  */ 

/»•••*•*•••*••****/ 

B4SFP  TFEE_BABF  := 

TtRFF  .SFIECP  M.L  .IF_»FS  (1,2,-B0-> 

( .T4BLE_TEST(1,1,"*")  .EBTEE  (1,1,"B") 

I .FBPTt~) 

.tiele_tfst(1,i,*b«)  .fef(1)  .fhfti  ; 

COEBIBATIOB  SOBSCFIPT  r= 

"SCOBBimTIOB" 

■(" 

.OOT ("BSOB SCRIPT  = “) 

1SITP_FFFBFSSI0B 
")  " 

.OOT(";")  ; 

C0B»FET_STBIBG_JF_1R1TF  := 

.SBTE_OS  E ( STB  *0 1) 

.EESFT  (STP*01) 

.TEST(TEEE_STRTBG_1RITB_SBITCB  = 3)  ^ 

.DO("BORB»I.  RFPGE_SBITCP  = HOBB4E_BEFGE_S»ITCF  + 1 , ) 

;ooT("iF  -,sTP*oi,-  = theb  = ‘*0 

•DO  ("HOEB»L_EFBGF_SSITCB  = »0BBI1._BERGF_SBITCF  - 1,  ) 
I .EBPTl  ; 

PFEB  FOR  ARITP  OPFBATOH  ;= 

~.PFEK  ("+"  I I "/"  I 

.SET(THEE_STPIBG_IR1TP_S»ITCB  = 3) 

.SFT  (FIEST_PBIRiEl_FOO»D_FLlG  = 1)  ; 

PF.EBOTiTIO*_SOBSCBIPT  : = 

■tPEREOTATIOB" 

"("  ^ 

.ODT  (*3S0B SCRIPT  = ") 


6? 


Fig.  1.4-2  (conci) 


ABITF_FIPRFSSIOS 

*1 

.OOT(":")  : 

POT_V4LOF  OB_DOBBT_BODF  := 

.SBIF_0SE (SOFT *0 1 , STR*0 1 , BOH*0 1) 

.PFSFT  (STE*01,BOB*01> 

.FRPTT 

.OOT  (SOFT*01 = 6BEB_BODE;") 

.OOT("CILL  aFFSFF?E(") 

( .TEST(TPFF_STFmG_AEITE_SltXTCE=2) 

.OOT  (STR»01) 

I .FBPTI 

.OOT  (FOB  *01)  ) 

.OOT  ("  ,aSOE(",SOFT*01,"))  ;•) 

.OOT  ("3S0B  ("  ,SOFT*01  ,")  = -aSOB  (",SOFT*01,")  ;“) 

.OOT  ("SSOFT_LIBK_ADDP  = ADDE  ("  ,SOFT*01 ,")  ;") 
.SET(PFAI._DDEB'T_SVITCF  = 2) 

( .TFST(T?ACF_FLAG  = 1) 

.OCT  ("IF  aTEACE  > 1 TPEB  CALL  aBODF_TPACF  (",SOFT*01,")  ;■) 

I .FHPTI  ) ; 


SFBI  COLOR  := 


.EBPTT 

.DO("aSTRT  = aSTBT  + 1;") 

";r  .FBR (""..SCABBY  (";"))  ; 

SFT_LABEL_EFPLACF_FLAG  r= 

.EBPTT 

.OOT(««LAEEL  EEPLACE_FLAG  = ■) 

( ( .TFST(LABFI_S0BSCPIPT_SBITCP  = 1) 

I .TrST(FFAL_DDEBT_S«ITCP=2)  ) 

.OOT  ("••F**;") 

I .EBPTT 

.OOT("*»T»»;*)  ) ; 

SETJDP_SOFT_SOR  r= 

.FBFTT 

.OOT(SOFT*01,"  = aSOR  (",SOFT*01,")  ;■) 

.OOT  ("IF  ",SOFT*01,"  < 0 TPEH  ",SOFT*01," 
SOFT_LIRK_SO»  ; 


0;") 


SOPT_LIFK_EFOTPER  r= 

.TFST(SFT_SOFT_LI»R_FLAG  = 1) 

.OOT  ("aS0FT_L3!iK_ADDF  = ADDE  (dBBOTPEE  (aS0FT_LIFR)  ) ;") 
r .ERPTT  ; ~ 

SOFT  LIRE  SOB  := 

'~.TPST(SET_SOFT_LI*K_FLAG  = 1) 

.OOT  ("aSOFT_LIIiK_ADDB  = ADDH  (aSOR(8SOFT_LI»K)  ) ;") 

? .EBPTT  ; 

TAKE  STATISTICS  := 

".TEST  (TAKE^STATISTICS_FIAG  = 1) 

.OOT  ("aCOORT  {■) 

.DO  ("CALL  BOOT  (STATISTICS_SRITCP)  ;") 

.OOT(")  = acOORTf") 

.DO  ("CALL  BOOT  (STATISTICS_SRITCE)  ;■) 

.OOT(")  + 1;") 

I .EBPTT  ; 

TRACEJOOTPOT  := 

.TEST  (TEACF_ALFFADT_ODTPOT_FLAG  = 1) 

I ( .TEST  (TEACE_FLAG  = 0)  “ 

.OOT  ("  ") 

I .EBPTT 

.OPT  ("CALL  aTBACF_STATEBERT  (") 

.DO  ("CALL  aoOT(aSTBT)  ;") 

.OOT(")  ■)  ) 

.OOT  ("  /*") 

.DO  ("CALL  aoOTOSTBT)  ;") 

.OOT  ("  •/; ")  ; 


.ERD 


cation,  and  briefly  discusses  the  reasons  for  those  which  do  not 
represent  additions  to  the  capabilities  of  the  language. 

Additions 

Option  list 

Node,  label“Value  storage  specification 

Statistics 

Trace 

Notes  option 
External  procedures 
Pointer  variables 
DO  FOR  ALL  SUBNODES  statement 
DEFINE  statement 
ADVANCE  statement 
Fixed,  floating  point  distinction 
Expanded  incremental  DO  statement 
Keyword  pointers  useable  outside  their  loops 
ALL:  in  PRUNE  statement 

String  literal  output 
Deletions 

Indirect  subroutine  call  - 

As  our  problem-solving  techniques  evolved  and  the  patterns 
^ of  use  of  the  language  become  clearer,  it  became  evident 
that  this  capability  is  not  required. 

String  expression  as  CALL  argument  - 

Allowing  the  user  to  call  a subroutine  using  a character 
string  as  an  argument  generates  logical  type  conversion 
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problems  which  were  not  forseen.  While  the  problems  can 
be  solved,  at  considerable  expense  in  translator  sophisti- 
cation, if  the  language  is  restricted  to  internal  procedures, 
our  expansion  to  include  external  procedures  renders  the 
solution  invalid. 

ALL  label  keyword  - 

This  provides  no  additional  functional  capability  and  was 
deleted.  Its  inclusion  in  the  functional  specification 
was  somewhat  vestigial,  since  the  language  feature  with 
which  its  beneficial  use  was  associated  had  already  been 
deleted  from  the  language  design  for  logical  reasons. 
Modifications 

Negated  boolean  expression  must  be  parenthesized  - 

This  is  necessary  to  avoid  syntactically  ambiguous 
expressions. 

Equality  relations  may  be  string  or  arithmetic,  as  deter- 
mined' at  execution  time,  and  need  not  be  differentiated 
by  the  programmer. 

It  proved  to  be  implementation-feasible  to  provide 
this  more  powerful  capability,  which  eliminates  the 
need  for  separate,  programmer-specified  relations 
for  the  two  data  types. 

FIRST,  FIRST; , and  ALL;  changed  from  label  to  subscript 
keywords . 
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This  was  done  to  increase  syntactic  consistency 
and  has  no  effect  on  the  functional  capabilities 


of  the  language. 
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DETAILED  DESIGN  SPECIFICATION  FOR  THE  PLANS  MODULE  LIBRARY 


This  section  extends  the  functional  design  specification  for  the 
PLANS  Module  Library  Volume  III  of  the  Phase  I Final  Report.  The 
extensions  include  details  on  how  each  module  is  to  be  implemented 
and  thus  constitute  a detailed  design  specification.  To  provide  a 
stand  alone  capability  in  Section  2,  the  four  digit  subsections 
previously  published  as  functional  specifications  are  repeated  in 
this  report  followed  by  the  additional  subsections  containing  details 
of  the  implementation  design.  For  reference,  Table  2-1  indicates 
those  subsections  of  this  document  that  appeared  as  functional 
specifications  in  Volume  III  of  the  Phase  I Final  Report. 

Section  2.1  provides  a brief  summary  of  the  PLANS  Module  Library 
Contents  and  characterizes  the  types  of  functions  that  the  modules 
perform.  Section  2.2  discusses  a general  operations  model  which  is 
a descriptive  framework  for  defining  scheduling  and  resource  allo- 
cation problems.  The  use  of  the  operations  model  conventions  pro- 
vides the  greatest  direct  applicability  of  the  Library  Modules. 

Since  the  input  and  output  of  all  library  modules  are  compatible 
with  the  operations  model,  a cursory  familiarity  with  it  is  necessary 
in  order  to  understand  the  functional  and  detailed  design  of  the 
individual  modules.  Section  2.3  discusses  the  format  of  presentation 
of  the  design  details  contained  in  the  subsequent  subsections. 

2,1  Description  of  the  Module  Library  Contents 

The  purpose  of  PLANS  Module  Library  is  to  provide  precoded  logic 
that  is  common  or  frequently  used  in  the  programming  of  scheduling 
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TABLE  2-1 


RELATIONSHIPS  OF  DETAILED  DESIGN 
SPECIFICATIONS  TO  PREVIOUSLY 
PUBLISHED  FUNCTIONAL  SPECIFICATIONS 


LIBRARY 

MODULES 

SECTIONS  OF  VOL.  Ill  OF 
PHASE  I FINAL  REPORT 
CONTAINING  FUNCTIONAL 
SPECIFICATIONS 

SECTIONS  OF  THIS  REPORT 
CONTAINING  DETAILED 
DESIGN  SPECIFICATIONS 

2.4.1 

DURATION 

2. 4. 1.1  - 2. 4. 1.6 

2.4. 1.7  - 2.4.1.10 

2.4.2 

ENVELOPE 

2. 4. 2.1  - 2. 4. 2. 6 

2. 4. 2. 7 - 2.4.2.10 

2.4.3 

INTERVAL JJNION 

2. 4. 3.1  - 2. 4. 3. 6 

2. 4. 3. 7 - 2.4.3.10 

2.4.4 

INTERVAL_INTERSECT 

2. 4. 4.1.  - 2. 4. 4. 6 

2. 4. 4. 7 - 2.4.4.10 

2.4.5 

FIND_MAX 

2.4.5. 1 - 2. 4. 5. 5 

2. 4. 5. 6 - 2. 4. 5. 9 

2.4.6 

FIND_MIN 

2. 4. 6.1  - 2. 4. 6. 5 

2.4  6.6  - 2. 4. 6. 9 

2.4.7 

CHECK  FOR_PROGESS_ 
DEFINITION 

2. 4. 7.1  - 2.4. 7. 5 

2. 4. 7, 6 - 2, 4. 7. 9 

2.4.8 

GENERATE_JOBSET 

2. 4. 8.1  - 2. 4. 8. 6 

2. 4. 8. 7 - 2.4.8.11 

2.4.9 

EXTERNAL_TEMP_RELATIONS 

2.4. 9.1  - 2. 4. 9. 5 

2. 4, 9. 6 - 2. 4. 9. 9 

2.4.10 

INTERNAL_TE1'!P_EE  LAT  IONS 

2.4.10.1  - 2.4.10.5 

2.4.10.6  - 2.4.10.9 

2.4.11 

ELEMENTARY_TEMP__RELAT  ION 

2.4.11.1  - 2.4.11.5 

2.4.11.6  - 2.4.11.9 

2.4.12 

NEXTSET 

2.4.12.1  - 2,4.12.6 

2.4.12.7  - 2.4.12.9 

2.4.13 

RESOURCE_PROFILE 

2.4.13.1  - 2,4.13.4  ■ 

2.4.13.5  - 2.4.13.9 

2.4.14 

POOLED  DESCRIPTOR_ 
COMPATIBILITY 

2.4.14.1  - 2.4.14.5 

2.4.14.6  - 2.4.14.9 

2.4.15 

DESCRIPTOR_PROFILE 

2.4.15.1  - 2.4.15.5 

2,4.15.6  - 2.4.15.9 

2.4.16 

UPDATE_RESOURCE 

■ 2.4.16.1  - 2.4.16.6 

2.4.16.7  - 2.4.16.9 

2.4.17 

WRITE_ASSIGNMENT 

2.4.17.1  - 2.4.17.7 

2.4.17.8  - 2.4.17.10 

2.4.18 

UNSCHEDULE 

2.4.18.1  - 2.4.18,6 

2.4.18.7  - 2.4,18.9 

2.4.19 

C0MPATIBILITY_SET_ 

GENERATOR 

2.4.19.1  - 2.4.19.6 

2.4.20 

FEAS IBILITY_PART IT ION_ 
GENERATOR  " 

2.4.20.1  - 2,4.20.7 

2.4.21 

PRO JECT_DECOMPO  SER 

2.4.21.1  - 2,4.21.8 

2.4.21.9  - 2.4.21.12 

2.4.22 

REDUNDANT  PREDECESSOR__ 
CHECKER 

2.4.22.1  - 2.4.22.8 

2.4.22.9  - 2.4.22.12 

2.4.23 

CRIT IC AL_PATH_C ALCULATOR 

2.4.23.1  - 2.4.23.9 

2.4.23.^10  - 2.4.23.13 
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TABIiii:  2-1  (CONTINUED) 


LIBRARY 

MODULES  . 

SECTION  OF  VOL.  Ill  OF 
PHASE  I FINAL  REPORT 
CONTAINING  FUNCTIONAL 
SPECIFICATIONS 

2.4.24 

PREDECESSOR_SET_ 

INVERTER 

2.4.24.1  - 2.4.24.7 

2.4.25 

network_condenser 

2.4.25.1  - 2.4.25.8 

2.4.26 

CONDENSED_NETWORK_MERGER 

2.4.26.1  - 2.4.26.8 

2.4.27 

network_assembler 

2.4.27.1  - 2.4.27.7 

2.4.28 

CRIT ICAL_PATH_PR0CESS0R 

2.4.28.1  - 2.4.28.7 

2.4.29 

network_editor 

2.4.29.1  - 2.4.29.8 

2.4.30 

CHECK  DESCRIPT0R_ 

compatibility 

2.4.30.1  - 2.4.30.6 

2.4.31 

order_by_predecessors 

2.4.31.1  - 2.4.31.8 

2.4.32 

resource_allocator 

2.4.32.1  - 2.4.32.8 

2.4.33 

resource_leveler 

2.4.33.1  - 2.4.33.9 

2.4.34 

heuristic_scheduling_ 

processor 

2.4.34.1  - 2.4.34.7 

2.4.35 

gub_lp 

2.4.35.1  - 2.4.35.9 

2.4.36 

mixed_integer_program 

2.4.36.1  - 2.4.36.9 

2.4.37 

primaljs  implex 

2.4.37.1  - 2.4.37.9 

2.4.38 

dual_simplex 

2.4.38.1  - 2.4.38.9 

2.4.39 

integer_program 

2.4.39.1  - 2.4.39.8 

2.4.40 

REQUIREI-IE>r:_GROUP 

generator 

2.4.40.1  - 2.4.40.6 

SECTIONS  OF  THIS  REPORT 
CONTAINING  DETAILED 
DESIGN  SPECIFICATIONS 

2.4.24.8  - 2.4.24.11 

2.4.25.9  - 2.4.25.12 

2.4.26.9  - 2.4.26.12 

2.4.27.8  - 2.4.27.11 

2.4.28.8  - 2.4.28.12 

2.4.29.9  - 2.4.29.12 
2.4.30.7  - 2.4.30.10 

2.4.31.9  - 2.4.32.12 


2.4.34.8  - 2.4.34.12 


2.4.40.7 
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and  resource  allocation  software.  A detailed  description  of  how  the 
functions  performed  by  various  modules  were  identified  can  be  found 
in  the  Appendix  of  the  Thase  I Final  Report  previously  published. 

The  Library  contains  programs  which  perform  the  functions  listed 
below: 

PREPROCESSORS 
PRELIMINARY  PROCESSORS 
ELEMENTARY  FUNCTIONS 
PERFOBMANCE  OR  CONSTRAINT  STATUS 
DATA  UPDATING 
ALGORITHMS 

In  the  Phase  I Study,  39  modules  were  functionally  specified. 
Those  specified  do  not  exhaust  the  possibilities  for  logic  that 
could  be  preprogrammed.  However,  since  Phase  I was  completed,  four 
typical  scheduling  programs  taken  from  NASA  applications  have  been 
implemented  and  86%  of  the  code  used  was  from  the  specified  Module 
Library.  This  provides  some  degree  of  confidence  that  the  functions 
provided  by  the  modules  are  common  to  scheduling  problems , 

Table  2.1- 1 provides  a concise  description  of  the  function  per- 
formed by  each  of  the  specified  modules.  Functional  and  detailed 
descriptions  constitute  the  subsections  of  Section  2.4  in  this  docu- 
ment. Some  examples  of  the  use  of  modules  can  be  found  in  Volume  II 
of  the  Phase  I Final  Report  previously  published. 

2.2  Description  of  the  Operations  Model  and  the  Standard  Data  Structures 
The  Operations  Model  is  a single  set  of  descriptive  conventions 
within  which  all  varieties  of  scheduling  and  resource  allocation 
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TABLE  2. 1-1 


CONCISE  DESCRIPTION  OF  THE 
PLANS  LIBRARY  MODULES. 


MODULE  MODULE 

CLASS  name 

PREPROCESSORS  CHECKJ’OR_PROCESS_DEFINITION 

NETWORK  EDITOR 


redundant  PREDECESSOR^CHECKER 


PRELIMINARY  GENERATE__J0BSET 

PROCESSORS 


PREDECESS0R__SET_INVERTER 

ORDERJBY_PREDECES  SOR 

CRITICAL__PATH__PR0CESS0R 
NETW0RK_ASS  EMBLER 

CRITI CAL_P ATH_CALCULAT0R 
CONDENS  ED__NETWORK_MERGER 


DESCRIPTION 

Checks  for  input  data  consistency. 

Identifies  and  eliminates  both  redun- 
dant predecessors  and  cycles  specified 
in  the  specification  of  precedence 
networks. 

Identifies  and  eliminates  redundant 
specifications  of  predecessors  in 
$ JOB SET. 

Creates  individual  jobs  for  each 
occurrence  of  a process  specified 
explicitly  or  via  an  operations  se- 
quence in  $OBJECTIVES.  Merges  in- 
formation contained  in  $OBJECTIVES, 
$OPSEQUENCE,  and  $PROCESS  into  a 
tree  called  $JOBSET. 

Creates,  from  a set  of  jobs  with  pre- 
decessors, an  equivalent  set  of  jobs 
with  successors. 

Produces  a list  of  jobs  where  all  jobs 
appear  in  the  list  only  after  all 
their  predecessors  have  appeared. 

Condenses,  merges  and  computes  cri- 
tical path  data  for  a master  network. 

Assem.bles  a master  network  from  sub- 
networks with  interfacing  events.  The 
relations  between  the  subnetworks  may 
be  more  general  than  those  describable 
by  nesting  operations  sequences. 

Calculates  early  and  late  start  and 
finish  times  as  well  as  total  and  free 
float  in  a network  of  jobs. 

Merges  two  condensed  networks  into  a 
single  composite  condensed  network, 
and  computes  the  critical  path  data 
for  the  composite  network. 
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TABLE  2.1-  KCONTD.) 


MODULE 

CLASS 

PRELIMINARY 

PROCESSORS 

(Continued) 


ELEMENTARY 

FUNCTIONS 


MODULE 

name  DESCRIPTION 


NETWORK__CONDENSER 
PRO JECT_DECOMPOS  ER 

COMPATIBILI  TY__SET_GENERAT0R 

FEAS IBLEJ?  ARTITI0N_GENERAT0R 

REQUIREMENT_GR0UP_GENERAT0R 

DURATION 

ENVELOPE 

ELEMENTARY_TEMP_RELATI0N 

WRITE_ASSIGNMENT 

INTERVAL_UNI0N 

INTERVAL  INTERSECTION 


Eliminates  activities  (jobs)  from 
a network  leaving  only  events  linked 
by  critical  delays  as  branches. 

Identifies  all  subprojects  within  a 
project  description;  i.e. , finds  sub- 
networks that  contain  app  predecessors 
and  successors  of  its  member  activi- 
ties. 

Enumerates  all  compatible  subsets  of 
an  input  set  using  externally  supplied 
compatibility  criteria, 

■Generates  all  sets  of  integers  with  a 
given  number  of  elements  that  sum  to 
a given  total. 

Generates  sets  of  jobs  as  a 
function  of  resource  commonality 
group . 

Calculates  the  duration  of  any  stand- 
ard (simple  or  multiple)  interval. 

Calculates  an  interval  that  is  the 
smallest  cover  of  a given  standard 
(simple  or  multiple)  interval. 

Checks  satisfaction  of  a single  bi- 
nary temporal  relation  given  specific 
assignments  for  the  two  jdbs  named  in 
the  temporal  relation. 

Writes  a single  assignment  for  a re- 
source and  adds  the  assignment  node 
in  chronological  order  in  $RESOURCE, 

Calculates  a standard  interval  that  is 
the  union  of  two  standard  intervals, 
i.e.,  all  points  in  the  output  standard 
interval  are  in  one  or  both  of  the  in- 
put standard  intervals. 

Calculates  a standard  interval  that  is 
the  intersection  of  two  standard  inter- 
vals, i.e,,  all  points  in  the  output 
standard  interval  are  in  both  the  in- 
put standard  intervals. 
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TABLE  2.1-1  (CONTD.) 


MODULE 

CLASS 

PERFORMANCE 
OR  CONSTRAINT 
STATUS 


MODULE 

NAME 


EXTERNAL  TEMP_RELATIONS . 


INTERNAL  TEMP  RELATIONS 


RESOURCE  PROFILE 


POOLED  DESCRIPTOR  COMPATIBILITY 


CHECK  DESCRIPTOR  COMPATIBILITY 


DESCRIPTOR_PROFILE 


DESCRIPTION 

Identifies  temporal  constraint  viola- 
tions that  would  occur  if  two  sets 
of  job  assignments  were  merged. 

Identifies  temporal  constraint  viola- 
tions that  exist  within  a set  of  job 
assignments.  Useful  in  finding  con- 
straint violations  after  multiple 
assignments  have  been  made  with  temp- 
oral constraints  relaxed. 

Determines  the  profile  of  a resource 
pool  over  a given  time  interval  for 
both  'normal'  and  'contingency'  levels. 
Determines  the  profile  of  the  assigned 
portion  of  a pool  and  gives  the  jobs 
to  which  the  resources  are  assigned. 

Determines  if  a single  assignment  of  a 
job  using  pooled  resources  with  expli- 
cit descriptors  is  (will  be)  compatible 
with  existing  descriptors  for  resources 
required  by  that  job. 

Determines  if  a single  assignment  of  a 
job  using  item-specific  resources  with 
explicit  descriptors  is  (will  be)  com- 
patible with  existing  descriptors  for 
resources  required  by  that  job.  Iden- 
tifies scheduled  jobs  that  change  the 
incompatible  descriptors. 

Determines  the  descriptors  for  an  item- 
specific  resource  that  are  valid  after 
a set  of  jobs  involving  those  resources 
have  been  scheduled.  Uses  the  assign- 
ment information  in  $RESOURCE  to  deter- 
mine the  descriptor  set  at  a particular 
time. 
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TABLE  2.1-  l(CONCL) 


MODULE 

CLASS 


ALGORITHMS 


DATA  UPDATING 


MODULE 

name  description 


FIND  MAX.  Finds  the  maximum  value  in  a numeric 

“ set  and  all  the  elements  that  have 

that  maximum  value. 

FIND  MIN  Finds  the  minimum  value  in  a numeric 

“ set  and  all  the  elements  that  have 

that  minimum  value. 


HEURISTIC__SCHEDULING_PROCESSOR  Performs  both  time-progressive  re- 
source allocations/ job  scheduling  and 
resource  leveling. 


RESOURCE_ALLOCATOR 

RESOURCE_LEVELER 

NEXISET 

INTEGER_PR0GRAM 

MIXED___INTEGER_PR0GRAM 

UPDATE__RESOURCE 

UNSCHEDULE 


Allocates  resources  to  jobs  to  satisfy 
all  resource  constraints  and  heuristic- 
ally  produce  a minimum  duration  schedule. 

Reallocates  resources  to  smooth  the 
usage  of  resources  while  maintaining 
schedule  constraints. 

Determines  a set  of  specific  resource 
items  to  meet  the  requirements  of  a job 
and  permit  the  earliest  possible  exe- 
cution of  that  job.  Determines  future 
times  the  job  requirements  can  be  met 
with  any  combination  of  appropriate  re- 
source types. 

Solves  the  linear  form  of  the  binary 
decision  making  problem. 

Solves  linear  programs  that  contain 
both  continuous  and  integer-valued 
decision  variables. 

Records  the  scheduling  of  a schedule 
unit  (job)  by  writing  assignments  in 
$RESOURCE  for  all  resources  used  in 
the  schedule  unit. 

Deletes  assignments  from  $RESOURCE 
for  all  resources  associated  with  a 
specified  job  to  be  deleted. 
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problems  can  be  defined.  Adherence  to  the  operations  model  con- 
ventions necessitates  a logical  partitioning  of  the  information 
associated  with  this  class  of  problems  according  to  the  categories 

below. 

PROCESSES:  Information  describing  any  activity  that  ultimately 
must  be  assigned  to  an  interval  on  the  timeline  and  which 
may  or  may  not  require  the  availability  of  resources  for 
that  interval.  Examples:  'Train  Crew’ , 'Transport  Payload' . 

RESOURCES:  Information  describing  any  elements  in  the  system 

that  are  required  for  one  or  more  processes  to  occur. 
Examples:  Crewpersons,  Payloads,  Trucks. 

OPERATIONAL  SEQUENCES:  Information  on  the  relationships  between 

processes  or  between  the  resources  associated  with  different 
processes.  Examples  'LoadJCruck'  precedes  'MoveJEruck' . 
Truck  used  in  'LoadJTruck'  is  same  Truck  as  that  used  in 
'Move_Truck'  . 

A schematic  representation  of  how  process,  and  resource,  and  re- 
lational descriptors  can  be  assembled  to  constitute  various  problem 

models  is  shown  in  Figure  2.2-1. 

Volume  II  of  the  Phase  I Final  Report  should  be  consulted  for  a 
description  of  each  element  shovm  in  the  Figure. 

Based  on  this  simple  partitioning  of  information,  blue  prints 
for  tree  structures  that  contain  this  information  have  been  devised. 
These  "standard  data  structures"  if  used  to  describe  the  problem 
being  solved,  permit  direct  use  of  the  library  modules.  See  Figures 
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2.2-2  through  2.2-9.  The  modules,  where  appropriate,  assume  that 
they  will  get  information  in  tree  formats  compatible  to  the  stan- 
dard data  structures.  It  should  be  clearly  understood  that  the 
standard  data  structures  need  not  be  used  to  code  in  PLANS,  and 
that  no  module  requires  all  the  information  shown  in  any  of  the 
standard  data  structures.  However,  the  information  required  as 
input  to  the  library  modules  is  assumed  to  be  arranged  with  the 
same  relationships  that  are  in  the  standard  data  structures.  Thus 
a module  requiring  an  interval  could  be  called  with  $INTERNAL  or 
with  $RESOURCE.ORBITER.ID__O06.ASSIGNMENT(l)  where  $INTERVAL  is 
shown  below. 

$INTERVAL 


The  trees  $RESOURCE,  $PROCESS,  and  $OPSEQ  contain  input  information 
about  the  sytem  to  be  scheduled.  $OBJECTIVES  contains  information 
on  the  particular  problem  to  be  solved,  i.e.  how  many  processes  must 
be  completed  to  constitute  a solution,  or  other  information  con- 
straining the  solution.  $JOBSET  is  a list  of  single  occurrences  of 
processes;  each  job  in  $JOBSET  must  be  assigned  time  and  resources 
before  the  problem  is  solved.  $SCHEDULE  is  a standard  format  for 
storing  a solution  to  a scheduling  problem.  Generally  the  problem 
formulator  would  not  build  $JOBSET  or  $SCHEDULE  but  rather  would 
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CONSIRAINT 


I IPROCESS  OR  OPSEQ  NAMO 


I (PROCESS  OR  OPSEQ  NAME)  ( ) (PROCESS  OR  OPSEQ  NAME) 


I SCHEDULE  TIME 


tTBMPORAL  RELATION 


rPROCESS"  I "OPSEQ")  (SEE  GENERAL  SUBSTRUCTURD 


Q ASSOCIATED 
RESOURCE 

(SEE  SU6STRUCTURE  Of  IPROCESS. 
NAME).  RESOURCB 


I PROCESS  NAME 


2.2-5  $OBJECTIVES  Standard  Data  Structure 


Fig.  2.2-6  $JOBSET  Standard  Data  Structure 
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(NUMERIC  CONSTANT) 


Fig.  2.2-8  TEiViPORAL  REUTION 


/ 


STANDARD  INTERVAL  FORMS 

1)  LABEL) 

This  is  a null  interval,  equivalent  to 


(value)  (value) 

This  is  an  ordinary  (single)  interval.  It  can  be  of  zero 
duration  if 

X. START  = X.END 


3) 

I 1 I 1 M 

time 

(value)  (value) 

This  is  a multiple  interval.  In  addition  to  the  usual  con- 
straint X. START  £ X.END,  it  is  also  required  here  that  for 
all  I < NUMBER(X),  X( I ) . END  £ X( I+l ) . START . 


Fig.  2.2-9  STANDARD  INTERVALS 
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■ cause  them  to  be  generated  from  $OBJECTIVE,  $OPSEQ,  $PROCESS,  and 

$RESOURCE  by  calling  library  modules  or  writing  his  own  PLANS  code. 

2.3  Format  for  Detailed  Design  Specifications 

Because  PLANS  is  a high-level  language,  single  statements  written 
in  PLANS  typically  perform  the  logic  contained  in  a single  block  of 
a functional  flow  chart.  In  fact,  a design  goal  of  PLANS  was  to 
virtually  eliminate  the  need  for  a detailed  design  step  in  the  soft- 
ware implementation;  l.e.  to  make  executable  code  easy  enough  to 
xvrite  that  functional  designers  could  use  the  language  themselves. 
Since  thirty-four  of  the  modules  functionally  specified  in  Phase  I 
are  most  appropriately  implemented  in  PLANS,  the  detailed  design 
specification  for  these  modules  would  typically  require  little  more 
detail  than  provided  in  the  functional  specification.  Yet  the  in- 
tent of  this  document  is  to  provide  greater  specificity  than  offered 
in  previous  documentation.  To  achieve  this  end,  the  appropriate  for- 
mat for  unambiguous  design  of  the  modules  seemed  to  be  PLANS  code 
itself.  Therefore,  a coding  of  the  modules  is  included  in  this  docu- 
ment. The  implementation  documentation  that  will  succeed  this  report 
may  show  substantial  modifications  to  the  code  presented  here.  Since 
the  intent  of  this  code  is  to  provide  a detailed  design  specification 
including  all  capabilities  described  in  the  functional  specifications, 
• it  is  not  optimized  for  computational  efficiency. 

Five  of  the  library  modules  are  appropriate  for  FORTRAN  coding 
rather  than  PLANS  coding  due  to  their  highly  algebraic  nature.  Two 
of  these  (INTEGER__PROGRAM,  MIXED__INTEGER_PROGRAM)  were  already  imple- 
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merited  and  checked  out  as  a feasibility  check  In  Phase  I.  The 
documentation  of  these  Implemented  codes  has  been  provided  to  NASA 
under  separate  documentation.  The  Phase  II  effort  does  not  Include 
the  prototype  Implementation  of  the  three  remaining  mathematical 
programming  modules  (PRIMAL^S IMPLEX,  DUAL_SIMPLEX,  GUBJ.P) ; there- 
fore sections  2.4.35,  2.4.37,  2.4.38  In  this  document  are  identical 
to  those  in  the  functiohal  specifications. 

Only  minor  deviations  from  the  functional  specifications  were 
deemed  desirable  in  generating  the  detailed  design  for  the  remaining 
34  modules.  In  all  cases,  these  modifications  extend  the  capabilities 
specified  previously  or  add  greater  consistency  between  modules.  All 
functional  modifications  are  noted  in  a subsection  entitled  "Modi- 
fications to  Functional  Specifications  and/or  Standard  Data 
Structures  Assumed". 
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2.4  Library  Module  Spiiiclf lea t Ions 

The  following  sections  present  detailed  functional  and  design 
specifications  for  the  PLANS  nodule  library.  Each  section  presents 
a different  module.  The  numbering  system  used  in  the  Phase  1 Final 
Report  has  been  preserved  In  this  volume. 


2. 4. 0-1 


2.4.1  DURATION 


2.4.1  DURATION 


2.4.1 


DURATION 


2. 4. 1.1  Purpose  and  Scope 

This  module  calculates  and  returns  the  duration  of  any 
standard  interval,  as  identified  in  the  section*  on  Standard  Data 
Structures.  If  the  interval  is  null,  the  returned  duration  is 
zero.  The  duration  of  a multiple  interval  is  defined  here  as  the 
sum  of  the  durations  of  its  constituent  simple  intervals. 

2. 4.1.2  Modules  Called 

I 

None 

2. 4. 1.3  Module  Input 

$ INTERVAL  is  any  standard  interval.  See  Fig.  2. 4.1-1  for  the 
minimum  required  data  structure  in  generic  form.  The  minimum 
required  data  structure  from  other  Standard  Data  Structures  is 
illustrated  in  Fig.  2. 4. 1-2. 

2. 4. 1.4  Module  Output 

DURATION_VALUE  is  an  arithmetic  variable. 

2. 4. 1.5  Functional  Block  Diagram 


2. 4. 1.6  Typical  Applications 

Any  applications  involving  intervals. 


2. 4. 1-1 


STANDARD  INTERVAL  FORMS 

$ INTERVAL 

1)  0(ANY  LABEL) 


This  is  a null  interval,  equivalent  to 

$INTERVAL 


(value)  (value) 

This  is  an  ordinary  (single)  interval.  It  can  be  of  zero 
duration  if 

X. START  = X.END 


(value)  (value) 


This  is  a multiple  Interval.  In  addition  to  the  usual  con- 
straint X. START  X.END,  it  is  also  required  here  that  for 

all  I < NUMBER(X),  X( I ) .END  < X( I+l) .START 
Fig.  2. 4. 1-1  Minimum  Required  Input  Data  Structures  for  Module:  DURATION 


2.4. 1-2 


Note;  Minimum  (relevant)  portion  of  required  input  standard  Data 

Structures  is  shown.  In  all  trees,  any  additional  structure 
will  be  preserved. 


$RES0URCE  $PR0CESS 


Fig.  2. 4. 1-2 

Minimwn  Required  Input  Structures  from  Standard  Data  Structures 
for  Module : DURATION 


2. 4. 1-3 
Rev  C 


$PROCESS 


$OBJECTIVE 


(value)  (value) 

Fig.  2. 4. 1-2  (oont) 


(value)  (value) 


2. 4. 1-4 


$OOBSET 


$JOBSET 


$JOBSET. 


(value)  (value) 

Fig.  2. 4. 1-2  (aonol) 


(value) 


(value) 
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2. 4. 1.7  DETAILED  DESIGN 


The  label  on  the  first  subnode  of  $INTERVAL  is  checked  to  see  if 
it  is  equal  to  'START*.  If  so,  a single  interval  structure  is  assumed, 
otherwise,  a multiple-interval  structure  is  assumed. 

2.4. 1.8  INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 


DURATION_VALUE  - used  to  return  value  of  the  total  duration 
$INTERVAL  - the  input  data  tree  that  contains  the  Intervals 

* to  be  summed 

2. 4. 1.9  MODIFICATIONS  TO  tUNCTIONAL  SPECS  AND/OR  STANDARD  DATA  STRUCTURES 


ASSUMED 


None 

2.4.1.10  COMMENTED  CODE 


DURATION!  PROCEDURE  (SINTERVaLi  OURATION.VALUE ) OPTIONS (EXTERNAL j I 

/***#*###****»*****e****#**«**#**<MHH»**<HHH>**<HHHH»*«**#**<»****<M»*#****/ 


/♦  */ 
/*  THIS  MODULE  calculates  THf  TOTAL  DURATION  OF  ALL  THE  TIME  */ 

/*  INTERVALS  SPECIFIED  IN  THf  INPUT  TREE*  SiNTERVAL.  THf  SUM  oF  */ 
/»  ALL  the  interval  DURATIONS  IS  RETURNED  IN  * DURATION.VALUE ♦ , 

/*  . , 


/****»«*****♦*#***♦#*****#*•#*******«»**♦**#»*«**»*«*****«**»*»#«*#♦#♦/ 
declare  SSU8_INtERVAL  local  I 
DURATION.VALUE  = 0.0  I 
IF  LABEL(SINTERVAL(FIRST) ) a ’START* 

THEN  DURATION^VALUE  » SjNTERVAL.END  - SINTERVAL.START  I 
ELSE  DO  FOP  ALL  «?UBNODEs  OF  SINTERVAL  USING  SSUBIiNTFRVAL  I 
DUPATION^VALUE  « DURATION-VALUE  ♦ $SUB_INTERVAL*EnD 

- SSUB.INTERVAL. START  I 

END  I 

END  I /*  duration  ♦/ 
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2,4.2  ENVELOPE 


2.4.2  ENVELOPE 


2.4.2  ENVELOPE 


2. 4. 2.1  Purpose  and  Scope 

This  module  generates  a simple  (or  null)  interval,  which  is 
the  smallest  covering  of  a given  (potentially  multiple)  interval. 
If  the  input  interval  is  null  or  simple,  the  envelope  interval 
is  identical  to  the  input  interval.  If  the  input  interval  is 
multiple,  the  envelope  interval  ranges  from  the  start  of  its 
first  constituent  interval  to  the  end  of  the  last. 

2. 4. 2. 2 Modules  Called 
None 

2. 4. 2. 3 Module  Input 

$INTERVAL  is  any  standard  interval.  See  information  under 
this  section  for  module  DURATION  for  minimum  required  data 
structure . 

2. 4. 2. 4 Module  Output 

$ENVEL0PE  is  a simple  (or  null)  interval. 

2. 4. 2. 5 Functional  Block  Diagram 


2 ,,4.2-1 


Any  applications  involving  intervals. 


2.4. 2-2 


2. 4. 2. 7  DETAILED  DESIGN 


The  label, on  the  first  subnode  of  $INTERVAL(1)  is  checked  to  see 
if  it  is  equal  to  'START'.  If  so,  multiple  intervals  are  assumed,  other 
wise,  a single  interval  is  assumed. 

2. 4. 2. 8 INTERNAL  VARIABLE  AND  TREE  NAME  DIFINITIONS 

$ENVELOPE  - the  output  tree  used  to  return  the  start  and  end 
values  of  the  envelope 

$INTERVAL  - the  input  tree  that  contains  the  interval (s) 

2. 4. 2. 9 MODIFICATIONS  TO  FUNCTIONAL  SPECS  AND/OR  STANDARD  DATA  STRUCTURES 
ASSUMED 

None 

2.4.2.10  COMMENTED  CODE 


ENVELOPE  I PROCEDURE  (SlNTERVALt  SENVELOPE)  OPTIONS (EXTERNAL) > 


/• 

/* 

/• 

/* 

/* 

/* 

/#♦»#♦*** 

IF  LABEL (SINTERVAL (FIRST) (FIRST)) 
then  SENVELOPE  a SINTERvAL  » 

ELSE  00  I SENVELOPE  « f INTERVAL (FIRST) I 

SENVELOPE. end  » SINTERVAL (LAST) .END  » 

END  I 

end  I /*  envelope  ♦/ 


THIS  MODULE  DETERMINES  THF  START  ANO  END  VALUES  OF  AN  ''ENVELOPE  */ 
THAT  COVERS  THE  INTERVALS  CONTAINED  IN  THE  INPUT  TREE.  SINTFRVaL.*^ 
THESE  VALUES  ARE  RETURNED  IN  THE  OUTPUT  TREE.  SENVELOpE,  f/^ 


'START* 
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2.4.3  INTERVAL_UN10N 


2.4.3  INTERVALJNION 

2. 4. 3.1  Purpose  and  Scope 

Given  two  standard  intervals,  this  module  constructs  a 

standard  interval  that  represents  their  union,  in  -the  sense  of 

the  sketch  below. 

$INTERVAL_A  I — ^ 

$INTERVAL_B  \ — 1 

$UNI0N  I — I I — H 

» 

2. 4. 3. 2 Modules  Called 
None 

2. 4. 3. 3 Module  Input 

$INTERVAL__A  and  $INTERVAL_B  are  standard  intervals. 

2. 4. 3. 4 Module  Output 

$UNI0N  is *a  standard  interval. 
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2 . 4 . 3 . 5 Functional  Block  Diagram 


2. 4. 3-2 


2. 4. 3. 6 Typical  Applications 


Any  applications  involving  intervals. 


2. A. 3. 7 DETAILED  DESIGN 


The  Inputs  to  this  module  can  be  of  two  different  types,  single  or 
multiple  standard  Interval  tree  structures.  Since  there  are  two  Inputs, 
there  are  four  possible  combinations  of  Input  structures.  To  avoid  having 
to  test  for  each  one  of  these  cases,  INTERVALJUNION  transforms  both  Inputs 
Into  multiple  Interval  structures.  Once  this  Is  done  the  structures  can 
be  Interpreted  by  the  same  block  of  code  without  regard  to  their  original 
form.  Of  course,  before  control  Is  returned  to  the  calling  program  both 
input  structures,  $INTERVAL_A  and  $INTERVAL_B,  are  transformed  back  to 
their  original  form.  This  approach  necessitates  only  one  general  block 
of  code  for  all  cases  and  makes  It  appear  that  the  Input  structures  have 
not  been  changed. 

In  order  to  facilitate  the  scanning  of  both  Input  Intervals  simul- 
taneously, a dummy  Interval  with  a start  time  of  INFINITY  Is  placed  at  the 
end  of  each  Input  tree.  Since  the  Intervals  are  selected  on  the  basis  of 
earliest  start  times,  this  Insures  that  all  Intervals  will  be  considered. 

As  new  Intervals  are  created  In  $UNION,  they  are  Inserted  before  the  first 
interval  already  in  $UNION.  Before  returning,  the  module  reverges  the  order 
of  these  intervals  so  that  they  will  appear  in  chronological  order. 

2.A.3.8  INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 
I_A  - used  as  a pointer  into  $INTERVAL_A 

I_B  - used  as  a pointer  into  $INTERVAL_B 

$INTERVAL_A  - an  input  standard  interval 

2.A.3-A 
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$INTERVAL_B 

$NEXT_INTERVAL 

NUMBER_A 

NUMBERJB 

$TEMP 

$UNION 

2. 4. 3. 9 MODIFICATIONS 
None 


an  Input  standard  Interval 

the  interval  currently  under  consideration 

the  total  number  of  intervals  in  $INTERVAL_A 
plus  one 

the  total  number  of  Intervals  'in  $INTERVAL_B 
plus  one  > 

used  as  a temporary  storage  area 

the  output  standard  interval  containing  the  union 
of  the  intervals  in  $INTERVAL_A  and  $INTERVAL_B 

TO  FUNCTIONAL  SPECS  AND/OR  STANDARD  DATA  STRUCTURES 
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2.4.3.10  COMMENTED  CODE 


/• 

/• 


/* 

/♦ 


I 


I 


INTERVAL^UNIONI  procedure  (SiNTERVAL  a*  SINTERVAL.Bf  SUNION) 

OPTIONS  (EXTERNAL)  I 

/*  input  to  this  module  consists  of  two  standard-interval  tree  « 

/*  STRUCTURES#  SInTERVAL^A  AnD  SINTERVAL.B.  THE  MODULE  BUlLOs  A i 
/•  SET  OF  intervals  REPRESENTING  THE  UNION  OF  THE  INPUT  INTERVALS  * 
/*  AND  RETURNS  IT  IN  SUNION. , ; 

DECLARE  I.A8_SWITCh# 

SPOINTER^AfSPOlNTER„B#SNEXT#$NEXT_lNTERVAL#SUNION'LAST  LOCAL  I 
/♦  INITIALIZE  variables  AND  TREE  STRUCTURES.  “ 4/ 

PRUNE  SUNION  f 

IF  Label (sintervalIa (FIRST))  « »start* 

Then  define  spointerIa  as  sinterval^a  i 
ELSE  define  SPOINTER.A  AS  SINTERVAL^A (FIRST) 

IF  label  (SINTERVAL1.B  (FIRST)  ) * »START» 

Then  define  spointer^b  as  sinterval^b  i 

ELSE  define  SPOINTER.B  aS  SINTERVAL.B (FIRST) 
define  SUNI0N.LAST  AS  SUNION (FIRST j I 
SUNI0N.LAST.END  » -INFINITY  t 
DO  while  (SPOINTERIA  NOT  IDENTICAL  TO  SNULL  I 

spointer.b  not  Identical  to  snull)  i 

OF  THE  remaining  INTERVALS#  THE  ONE  WITH  THE  EARLIEST  START 

time  is  considered  next. 

IF  SP0INTER.B  IDENTICAL  TO  SNULL  I (SPOINTER  A 

- identical  to  snull  & SPOINTERIa. START  <*$POlNTER.B.sfART) 
THEN  DOI  DEFINE  SNExT  AS  SPOINTER.AI  I.AB.SWITCH  » I|  fNDi 
ELSE  DOI  define  SNExT  AS  SPOINTER.BI  I.AB.SWITCH  = 2t  rNOl 
SNEXT..INTERVAL. START  a SNEXT, START  I 

snext.interval.eno  * snext.end  I 

NOW  THE  intervals  IN  SUNION  CAN  BE  MODIFIED  BASED  ON  THE  START 

And  end  times  of  the  interval  under  consideration.  i/ 

IF  SNEXT.INTERVaL. start  > SUNIOnIlAST.END 
THEN  DO  I ADVANCE  S|)NJ0n|lAST  I 

graft  SNExT.INTERVAL  at  SUNION.LAST  I 

end  I 

ELSE  IF  SNEXT.INTERVk.END  > 

^ Then  $union.last.end 

IF  I.AB.SWITCH  a 1 

then  advance  SPOINTER.A  I 
ELSE  ADVANCE  SPOINTEr.B  I 
End  I 

PRUNE  SUNION(FIRST)  I 
END  INTERVAL^UNION  I 


#/ 

»/ 


$union.last.end 

a SnEXT.INTERVAL.END  I 
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2.4.4  INTERVAL  INTERSECT 


.4.4  INTERVALJNTERSECT 

2. 4. 4.1  Purpose  and  Scope 

Given  two  standard  intervals,  this  module  constructs  a 
standard  interval  which  represents  their  intersection,  in  the 
sense  of  the  sketch  below. 

$INTERVAL_A  j- j 

$INTERVAL__B  | — — I 

$INTERSECTION  \ 1 

2. 4. 4. 2 Modules  Called 
None 

2. 4. 4.3  Module  Input 

$INTERVAL_A  and  $INTERVAL_B  are  standard  intervals. 

2 . 4 . 4 . 4 Module  Output 

$ INTERSECTION  is  a standard  interval,  a point  intersection  will 
be  detected  by  INTERVAL_INTERSECT  thus  the  calling  program  must  check 
for  and  prove  zero  duration  intersections  if  they  are  not  required. 


2.4. 4-1 
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2. A. 4. 5 Functional  Block  Diagram 


2. 4. 4-2 


2. 4. 4. 6 Typical  Applications 

Any  applications  Involving  inliervalt*. 


2. 4. 4. 7 DETAILED  DESIGN 

Th«  input*  to  this  module  can  ba  of  two  different  types ^ single 
or  multiple  standard  interval  tree  structures.  Since  there  are  two 
inputs,  there  are  four  possible  combinations  of  input  structures.  To 
avoid  having  to  teat  for  each  on*  of  these  cases,  1NTERVAL_INTERSECTI0N 
transforms  both  inputs  into  multiple  interval  structures.  Once  this  is 
done  the  structures  can  be  interpreted  by  the  same  block  of  code  with- 
out regard  to  their  original  form.  Of  course,  before  control  is  returned 
to  the  calling  program  both  input  structures,  $INTERVAL__A  and  $INTERVAI._B, 
are  transformed  back  to  their  original  form.  This  approach  nacessitatee 
only  one  general  block  of  code  for  all  cases  and  makes  it  appear  that  the 
input  structures  have  not  been  changed . 

In  order  to  facilitate  the  scanning  of  both  input  intervals  simultan- 
eously, a dummy  Interval  with  a start  time  of  INFINITY  is  placed  at  the 
end  of  each  input  tree.  Since  the  intervals  are  selected  on  the  basis  of 
earliest  start  times, thia  insurea  that  all  Intervals  will  be  considered. 

As  new  intervals  are  created  in  $ INTERSECT ION,  they  are  inserted  before  the 
first  interval  already  in  $ INTERSECT ION.  Before  returning,  the  module 
reverses  the  order  of  those  Intervals  so  that  they  will  appear  in  chrono- 
logical order . 
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2 . 4 . 4 . 8 INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 


I A 

- 

used  as  a pointer  into  $ INTERVAL  A 

IB 

- 

used  as  a pointer  into  $INTERVAL_B 

$INTERSECTION 

- 

the  output  standard  interval  containing  the 
intersection  of  the  Intervals  in  $INTERVAL_A 
and  $INTKRVAL_B 

$INTERVAL_A 

- 

an  input  standard  Interval 

$INTERVAL_IJ 

- 

an  input  standard  interval 

$NEXT_INTERVAL 

- 

the  Interval  currently  under  consideration 

number  A 

- 

the  total  number  of  intervals  in  $INTERVAL_A 
plus  one 

NUMBER_B 

- 

the  total  number  of  Intervals  in  $INTERVAL_B 
plus  one 

$TEMP 

- 

used  as  a temporary  storage  area 

2. 4. 4. 9 MODIFICATIONS 

TO  FUNCTIONAL  SPECS  AND/OR  STANDARD  DATA  STRUCTURES 

None 
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2.4.4-10  COMMENTED  CODE 


INTERVAL-INTERSECTj  . , . 

/*****#*«#»*#*♦*##♦#*•**#*♦•»*#«•***»**•*•<>*•*♦*•***<****♦♦♦*'***«♦*****/ 


/♦  c 

/#  INPUT  TO  this  module  CONSISTS  OF  TWO  STANDARD-INTERVAL  TREE  */ 

/•  STRUCTURES*  $INTERVAL«A  AnD  SINTERVAlIb.  THE  MODULE  BUILDS  A */ 

/*  SpT  OF  intervals  REPRESENTING  THE  INTERSECTION  OF  THE  INPUT  */ 

/♦  intervals  AND  RETURNS  IT  IN  SINTERSECTION,  #/ 

/♦  . . 
/##****#**#**♦♦**#**»#♦**»#**»»«*******<»*«***********<»♦*♦»♦*»*****#*♦*  ‘ 

procedure  (SINTeRVAI A*  SINTErValIBi  SINTERSECTION)  OPTIONS (EXTERNAL) I 

declare  I_A*I_B*NUmrER.A*NI)MBErI!8»STEMP*SNEXT..INTERVAL  local  I 

/♦  initialize  variables  and  tree  structures.  * 


PRUNE  SINTERSECTION  I 

IF  SINTERVAL.A (FIRST)  IDENTICAL  TO  *NuLL  I 

SINTFRVAL_B  (FIRST)  IDENTICAL  TO  SNULL  THEN  RETURN  I 
IF  LABEL(SINTERVAL_A(FIRSTU  «istart* 

THEN  001  graft  SINTERVaL.A  AT  STEMPi 

graft  STEMP  at  SiNTERVALlA(FlRST) I 

END! 

IF  LABEL(SINTERvAL_B(FIRST{  ) »»START* 

THEN  DO!  graft  SInTERVAL.R  AT  STEMP* 

GRAFT  STEMP  AT  SINTERVALIb (FIRST) » 

END* 

SINTERVAL»A(NEXT) .START  a INFINITY  I 
SINTERVAL«B(NEXT) .START  a jNFlNlTY  ; 

NUMBER.A  * NUMBER  (SINTERVAL„A)  I Ig^A  a \ | 

NUM8ER.B  * NUMBER (SINTERVAlIb)  I lUB  a i | 

STEMP, END  « -infinity  * 

DO  while  (I-a  < number^  \ I^B  < nUMBER^B)  * 

/*  OF  THE  remaining  INTERVALS.  THE  ONE  WITH  THE  EARLIEST  START  #/ 

/•  time  is  considered  next.  */ 

IF  SINTfRVAL.A(i1a) .start  < $INTERVAL_B(I_B) .START 

THEN  DO  * SNEXT.INTfRVAL  * ’ SINTERVAL«A ( I„A ) * I_A  » i^i+l  | 
End  I , , 

ELSE  DO  * $NEXT_INTfRVAL  = SINTERVALIB ( I.B)  * I.B  « I„R+1  I 
END  I , , . 

/♦  NOW  THE  INTERVALS  IN  SINTfRSECTION  CAN  BE  MODIFIED  BASED  ON  THF  */ 
/#  START  AND  end  TIMES  OF  THp  INTFRVAL  UNDER  CONSIDERATION. 

IF  SNEXT^INTfRVaL. start  > STEMP, END 
THEN  graft  SNFXT.INTfRVAL  AT  sTEMP  t 
ELSE  IF  SNEXT_INTeRVaL.END  < sTEMP.END 

Then  graft  insert  snext.interval 

before  SINTERSECTION(FIRST)  I 

else  do  * , ... 

insert  SmEXTIinTERVAL  before  SINTERSECTION(FIRST) I 
SINTERSFCTTON(FirST) .END  a STEMP, END  * 

GRAFT  SmEXT^INTERVAL  AT  STEMP  * 

END  » 

end  I 

/#  PUT  THE  intervals  OF  SINTERSECTION  IN  CHRONOLOGICAL  ORDER.  */ 

GRAFT  SINTERSECTION  AT  STEmP  I 
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00  I«1  TO  number <STEMP)  I 

graft  insert  STEMP(FIRST)  before  SINTERSECTION(FIRST)  I 
END  I 

PRUNE  SINTERVAL.A(LAST) ?SInTERVAL_B(LAST)  I 
IF  NUMBER. A « 2 

THEN  001  graft  SINTERVAL.A (FIRST) ^ AT  STEMP! 
graft  STEMP  at  SiNTERVALiiA* 

END  I 

IF  NUMBER.B  « 2 

THEN  DO!  graft  SINTERVAL.R (FIRST)  aT  STEMPI 
graft  STEMP  AT  $TNTERVAl1b» 

END  I 

PRUNE  STEMP  I 


END  INTERVAL.INTERSECTION  I 


2.4.5  FIND  MAX 
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2.4.5  FIND_MAX 

2. 4. 5.1  Purpose  and  Scope 

Given  a set  of  numerical  values  (i.e.,  a node  of  a tree  for 
which  each  of  the  next  lower  level  subnodes  is  terminal  and  has 
a numerical  value)  , find  the  maximum  of  the  values  and 
^ find  the  indices  (i.e.,  the  ordinal  positions  in  the  original 
set)  of  each  of  the  subnodes  for  which  the  value  equals  the 

maximum . 

2. 4. 5. 2 Modules  Called 
None 

2. 4. 5. 3 Module  Input 

$SET  is  a tree  of  the  form  shown  in  the  sketch.  Minimum 
required  data  structure  is  a tree  with  at  least  one  subnode  at 
the  next  lower  level. 


$SET 


Each  value  is  numeric, 

2 . 4 . 5 . 4  Module  Output 

VALUE_MAXIMUM  is  an  arithmetic  variable  whose  value  is  the 
maximum  of  the  values  of  $SET.  a 
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$INDICES  is  a tree  of  the  form 


$INDICES 


(index)  (index) 


where  the  indices  are  the  ordinal  positions  in  $SET  of  all  nodes 
whose  value  equals  VALUE_MAXIMUM. 
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2. 4. 5. 6 DETAILED  DESIGN 


This  module  iteratively  searches  through  the  numeric  values  of  the 
subnodes  of  $SET.  As  the  subnod.es  are  scanned,  the  current  maximum  is 
maintained  by  comparing  each  value  with  it.  $INDICES  and  the  VALUE_ 
MAXIMUM  are  updated  every  time  a larger  value  is  encountered.  If  $SET 
is  empty,  -INFINITY  is  returned  as  the  maximum  value. 

2. 4. 5. 7 INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 


I 

- 

is  a counter  used  to  obtain  subnodes  indices 

$INDICES 

- 

used  to  record  the  Indices  of  the  subnodes  whose 
value  equals  the  maximum 

$SET 

- 

is  the  set  of  numeric  values 

$VALUE 

- 

is  one  of  the  subnodes  of  $SET 

VALUE_MAXIMUM 

used  to  return  the  maximum  value  to  the  calling 
program 

2 . 4 . 5 . 8 MODIFICATIONS  TO  FUNCTIONAL  SPECS  AND/OR  STANDARD  DATA  STRUCTURES 


In  addition  to  returning  the  appropriate  subscripts  in  $INDICES,  this 
tree  is  also  used  to  return  the  node  labels.  Of  course,  node  references  by 
subscript  are  y.ore  efficient  than  references  by  label.  Therefore,  the  user 
is  not  encouraged  to  use  these  labels  to  reference  the  subnodes  of  $SET  since 
the  corresponding  indices  are  also  available. 

The  variable  name  VALUE_MAXIMUM  was  substituted  for  MAXIMUM  in  order 
to  allow  for  real  as  well  as  integer  values. 
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COMMENTED  CODE 


find  maxi  procedure  (SSET*  SiNDiCESf  VALUE„MAX1MUM) 

OPTIONS(EXTeRNaL) I 

/***#*«#«**#**«#***«'*»«‘*******<^***************************************^ 


THIS  procedure  FINDS  THE  LARGEST^ VALUE  IN  THE  NUM^IC  SET  INPUT 
IN  $SET  AND  RETURNS  IT  IN  t valUE.MaXIMUM*  . 

TREEf  SINDICES,  CONTAINING  THE  LABELS  AND  SUBSCRIPTS  THAT  COR- , 
RESPOND  TO  THE  SUBNODES  Of  SSET  WhoSE  VALUES  EQUAL  THE  MAXIMUM. 
IF  $SET  IS  NULL*  -INFINITY  IS  RETURNED  AS  THE  • VALUE^MAXIMUM* . 


/♦ 

/♦ 

/♦ 

/• 

/* 

/* 

/****#*<M»»**«*«-»**«<»<»*<»**<*<»******^^*****^******‘‘************************^ 

DECLARE  I*SVaLUE  LOCAL  » I ® 0 I 
VALUE.MAXIMUM  ■ -INFINITY  t 
DO  FOR  ALL  SUBNoDES  OF  SSET  USING  SVALUE  I 
I a !♦!  I 

IF  SVALUE  > VALUE^MAXIMUM 

THEN  DO  I VALUE^AXiMUM  = SVALUE  » 

PRUNE  SINdICES  I 

$INDICESa#LABEL(5VALUE)  s I » 

end  I 

ELSE  IF  SVALUE  * VALllE^MAXIMUM 

THEN  DO  I StNDICES(NEXT)  * I f 
LaBEL(SINDICES(LAST) ) 

END  I 


X label (SVALUE)  I 


END  I 

END  I /♦  FIND-MAX  «/ 
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'S.'N.'N.i'V  'W.'Xi 


2.4.6  FIND_MIN 
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Rev  C 


NllAI  QNld  9 VZ 


2.4.6  (INDJ1IN 

2. 4. 6.1  Purpose  and  Scope 

Given  a set' of  numerical  values  (i.e.,  a node  of  a tree  for 

which  each  of  the  next  lower  level  subnodes  is  terminal  and  has 

a numerical  value) , find  the  minimum  of  the  values  and  find  the 

indices  (i.e.,  the.  ordinal  positions  in  the  original  set)  of  each 

of  thd  subnodes  for  which  the  value  equals  the  minimum. 

« 

2. 4. 6. 2 Modules  Called 
None 

2. 4. 6. 3 Module  Input 

$SET  is  a tree  of  the  form  shown  on  the  sketch  with  at  least 
one  subnode  at  the  next  lower  level. 


$SET 


Each  value  is  numeric. 

2 . 4 . 6 . 4  Module  Output 

VALUE_MINIM[JM  is  an  arithmetic  variable  whose  value  is  the 
minimum  of  the  values  of  $SET. 
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$INDICES  is  a tree  of  the  form 


$1NDICES 


where  the  indices  are  the  ordinal  positions  in  $SET  of  all  nodes 
whose  value  equals  VALI]E__MINIMUM. 
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2 . 4 . 6 . 5 Functional  Block  Diagiram 
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2. 4. 6. 6 DETAILED  DESIGN 

This  module  Iteratively  searches  through  the  numeric  values  of  the 
subnodes  of  $SET.  As  the  subnodes  are  scanned,  the  current  minimum  is 
maintained  by  comparing  each  value  with  it.  $INDICES  and  the  VALUE_ 

MINIMUM  are  updated  every  time  a smaller  value  is  encountered.  If  $SET 
is  empty,  +INFINITY  is  returned  as  the  minimum  value. 

2. 4. 6. 7 INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 

I - is  a counter  used  to  obtain  subnodes  indices 

$INDICES  - used  to  record  the  indices  of  the  subnodes  whose 

value  equals  the  minimum 

$SET  - is  the  set  of  numeric  values 

$VALUE  - is  one  of  the  subnodes  of  $SET 

VALUE_MINIMUM  - used  to  return  the  minimum  value  to  the  calling 

program 

2. 4. 6. 8 MODIFICATIONS  TO  FUNCTIONAL  SPECS  AND/OR  STANDARD  DATA  STRUCTURES 
In  addition  to  returning  the  appropriate  subscripts  in  $INDICES,  this 

tree  is  also  used  to  return  the  node  labels.  Of  course,  node  references  by 
subscript  are  more  efficient  than  references  by  label.  Therefore,  the  user 
is  not  encouraged  to  use  these  labels  to  reference  the  subnodes  of  $SET  since 
the  corresponding  indices  are  also  available. 

The  variable  name  VALUE_MINIMUM  was  substituted  for  MINIMUM  in  order 
to  allow  for  real  as  well  as  integer  values. 
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2. 4. 6. 9 COMMENTED  CODE 


FIND.MINI  procedure  (SSEtf  SINDICES#  value  MINIMUM) 
OPTIONS (EXTERNAL) I 


/• 

/* 

/* 

/♦ 

/* 

/• 

/*********»®**************<»*o***#***#******»***»*»*»***#**##*##***^##* / 

declare  ItSVALUE  LOCAL  I I « 0 I 

VALUE^MINIMUM  » INFINITY  J 

DO  FOR  ALL  SUBNoDES  OF  SSET  USING  SVALUE  I 

I ■ I 

IF  SVALUE  < VALUE^MINIMUM 

Then  do  i vaLue^intmum  « svalue  i 
PRUNE  SI No ICES  I 
SINDICES,#LABEL(SvaLUE)  « I I 

end  f 

ELSE  IF  SVALUE  * VALUEIminIMUM 

then  do  I StNDICES(NEXT)  « I I 

LaBEL(SINDICES(LAST) ) = LABEL(SVALUE)  I 

END  ? 

End  I 

END!  /•  FInD»MIN  */ 


_ */ 
THIS  procedure  FINDS  THE  SMALLEST  VALUE  IN  THE  NUMERIC  SET  INPUT  */ 
IN  SSET  AND  RETURNS  IT  IN  » VALUE1mINIMUM» • IT  ALSO  OUTPUTS  A */ 
TREE#  SINDICES#  CONTAINING  THE, LABELS  AND  SUBSCRIPTS  THAT  COR-  #/ 
RESPOND  TO  THE  SUBNODES  OF  SSET  WhoSE  VALUES  EQUAL  THE  MINIMUM.'  */ 
IF  SSET  IS  NULL*  ♦INFINITY  IS  RETURNED  AS  THE  • VALUE.MINI MUM » . »/ 


cz ' 
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2,4,7  CHECK_FOR_PROCESS 
DEFINITION 


2.  A. 7 CHECK__FOR_PROCESS_DEFINITION 

I 

2. 4. 7.1  Purpose  and  Scope 

' This  module  checks  that  all  processes  or  operations  sequences 
specified  in  $OBJECTIVE  are  defined  in  $PR0CESS'or  $0PSEQ.  These 
processes  may  be  listed  explicitly  or  contained  in  an  operations 
sequence  specified  in  $OBJECTIVES.  If  any  processes  are  not  .. 
included  in  $PR0CESS,  such  information  as  process  duration  and 
required  resources  are  not  defined.  Since  this  condxtion  pre- 
cludes successful  execution  of  the  problem,  the  missing  processes 
should  be  identified.  This  module  performs  that  xdentificatxon 

function . 

2. 4. 7. 2 Modules  Called 
None 

2. 4. 7. 3 Module  Input 

Input  to  this  module  consists  of  $OBJECTIVES,  $0PSEQ  and 
$PR0CESS.  The  minimum  required  data  structure  from  these  Standard 
Data  Structures  is  illustrated  in  Fig.  2.4.7 -1, 

2. 4. 7. 4 Module  Output 

This  module  will  output  a tree  structure,  $MISSING.  with  the 
names  of  unfound  processes  and  operations  sequences.  If  this  tree 
is  null,  no  missing  definitions  have  been  xdentxfied. 
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Note:  Minimum  (i.e.  relevant)  portion  of  required  input  Standard 

Data  Structures  is  shown.  In  all  trees,  any  additional 
structure  will  be  preserved. 


SOBJECTIVES 

ft 


ft 

ft 

9 


OPSEQ 


(NAME) 


TYPE 

(value) 


$0PSEQ 


(OPSEQ 

NAME) 


(ELEMENT 

NAME) 


(value) 


SPROCESS 


^t^^nlmReqidred  Input  Structures  from  Standard  Data  Structures  for 
Module:  CHECK__FOR_PROCESS_DEFINITION 
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2. 4. 7. 5 Functional  Block  Diagram 


ORIGINAL  PAGE  IB 
OF  POOR  QUALITY 
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2 . 4 . 7 . 6 Typical  ApplicaLions 

This  module  is  useful  for  initial  problem  processing,  which 
checks  for  logical  errors  or  incomplete  data. 
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l,k.l  *1  Detailed  Design 


The  functional  block,  diagram  provides  the  flow  chart  for  this  module. 

The  module  selects  each  subnode  under  OPSEQ  In  the  $OBJECTIVES  tree.  For 
each  element  an  Internal  procedure,  CHECK_PROC_RECURSIVE  Is  called  resurslvely. 
This  procedure  determines  whether  the  current  element  Is  an  operations  se- 
quence or  a process.  If  the  element  Is  a process,  $PROCESS  is  interrogated 
to  verify  the  current  element  is  Included,  if  not,  the  current  element 
label  Is  added  to  $MISSING.  If  the  element  is  determined  to  be  an  operations 

I 

sequence,  $OPSEQ  la  interrogated  to  verify  the  current  element  is  included, 
if  not  the  current  element  label  is  added  to  $MISSING.  Otherwise  each  sub- 
node is  selected  and  the  procedure  CIIECK_PROC_RECURSIVE  is  repeatedly  called 
until  all  processes  have  been  checked . 

2 . 4 . 7 . 8 Internal  Variable  and  Tree  Names 
None 
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2.4.7. 9 Commented  Code 


CliECK_FOR_PROCESS..DEFlNlTION:  PROCEDURE  (SOBJECT IVES. $OPSEQ,SPROCES^f 
SMISSING)  OPTiONS(EXTfRNAL) I 
PRUNE  SMISSING* 

DO  I s 1 To  NUMBER(SORJEcTIVeS.OPSEQ) I 
call  CHECK_pR0C.RECURSIVr  tSORJECTlVES.OPSEQ ( I ) ) * 
CHECK_PRoC_RECURSIVFJ  PROCEoURE (S0PSEQ„0R_PR0C)  RECURSIVE* 

DECLARE  J local? 

IF  SOPSEO_OR_PROC.TYPE  = »OP$EQ»  THEN  DO* 

CHECK.OPSEO: 

IF  $opseq.#label{sopseq«.or1proc> 

IDENTICAL  TO  SNULL 

then  SMISSING, OPSEQ<NfXT)  s LABEL ( SOPSEQ.OR^PROC) * 

ELSE  no  J = 1 TO  NUMBER($OPSEQ.«LABEL(SOPSEQ.OR|pROCj ) I 
call  CHfCK1pROC_RECURS1VE (S0PSE0.#LABEL(S0PSEQ_0R1PR0C) 

( J) ) t 
END* 

return* 

END* 

ELSE  IF  $PROCESS,«LABEL<SOPSE01orLpROC) 

IDENTICAL  TO  SNULL 

then  SMISSING. process (NEXT)  = LABEL (SOPSEQ^OR.PROC) * 

return* 

end  * CHECK_PPOC_RFCURSlVE  «/ 

end  * 

END  * /*  check_for_process1definition  */ 
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2,4.8  GENERATE  JOBSET 


2.4.8 


GENERATE  OOBSET 


2.4. 8.1  Purpose  and  Scope 

This  will  create  a set  of  jobs  by  examining  the  con- 

tents of  the  data  trees.  $OBJECTIVES,  $0PSEq.  and  $PR0CESS.  Each 
job  will  represent  a single  occurrence  of  a process.  It  will  create 
an  output  data  tree  that  contains  unique  nodes  for  each  job  iden- 
tified. 

This  module  will  build  a data  tree,  $JOBSET,  containing  only 
the  jobs  that  are  identifiable  from  the  input  trees  $0BJECTIVES, 
$0PSEQ,  and  $PR0CESS.  The  jobs  will  be  grouped  under  first-level 
subnodes,  each  of  which  represents  the  occurrence  of  an  operations 
sequence.  Because  operations  sequences  may  be  nested,  only  those 
at  the  highest  level  of  nesting  will  cause  a first-level  node  of 


$J0BSET  to  be  built.  If,  during  the  execution  of  a scheduling 
problem,  implied  jobs  are  scheduled,  these  jobs  may  be-  added  to 
the  trees  created  by  this  module;  however,  the  GENERATEJOBSET 
module  will  not  put  implied  jobs  into  the  jobset  since  implied 
jobs  cannot  be  identified  from  $OBJECTIVES,  $0PSEQ,  and  $PR0CESS. 

The  output  of  this  module  will  be  ordered  by  a set  of  unique 
job  identifiers,  but  the  ordering  of  the  identifiers  will  have 
no  implication  on  the  temporal  order  in  which  the  jobs  must  be 
scheduled . 


Each  job  created  by  this  module  will  have  associated  with  it 
the  most  specific  resource  information  contained  in  either 
$OBJECTIVES  or  $PR0CESS.  If  resource  alternatives  are  defined 
in  $PR0CESS,  a separate  job  identifier  will  be  assigned  to  each 
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process-resource  combination.  Where  process  alterna.i.ives  are 
indicated  in  $OBJECTIVES  or  $0PSEQ,  all  alternatives  will  also  be 
assigned  a unique  job  identifier.  This  module  will  write  the  job 
identifiers  for  all  alternatives  under  each  job.  For  example,  if 
Jobs  1,  2,  and  3 are  mutually  substitutable,  a unique  node 
wiXT  appear  in  the  output  $J0BSET  for  each  of  the  three  jobs. 

The  node  ALTERNATIVE  under  Job  1 would  contain  subnodes  JOB  2 
and  JOB  3,  the  node  ALTERNATIVE  for  Job  2 would  contain  sub- 
nodes JOB  1 and  JOB  3,  etc.  It  is  recognized  that  if  no  implied 
jobs  are  rescheduled  the  number  of  jobs  in  the  final  schedule 
will  always  be  less  than  or  equal  to  the  number  of  jobs  in 

$J0BSET, 

Temporal  relations  between  elements  of  an  operations  sequence 
will  be  included  in  the  output  tree  $J0BSET . The  module  will, 
hovrever,  replace  a generic  process  name  that  appears  as  a value 
under  a TEf1P0RAL_RELATI0N  node  with  an  appropriate  specific  job 
identifier.  If  the  element  name  that  appears  under  a 
TEMP0RAL_RELATI0N  node  with  an  appropriate  specific  job  identi- 
fier. If  the  element  name  that  appears  under  a TEf1P0RAL_RELATI0NS 
node  is  itself  an  operations  sequence,  a separate  subnode  will  be 
written  for  each  job  in  that  operations  sequence. 

2 . 4. 8 . 2 Modules  Called 
None 
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2. 4. 8. 3 Module  Input 


The  input  to  this  module  consists  of  the  trees,  $OBJECTIVES, 
$0PSEQ,  and  $PR0CESS,  defined  previously,  and  the  integer 
INITIAL_ID.  The  minimum  required  data  structure  from  these  stand- 
ard structures  is  shown  in  Fig.  2. 4.8-1.  INITIALJD  is  the  first 
integer  to  be  used  in  constructing  unique  job  identifiers  within 


the  module. 

2. 4. 8. 4 Module  Output 


This  module  will  retutn  an  output  tifee  $J0BSET  to  the  calling 
program.  It  will  contain  the  RESOUB.CE  information  from  $PROCESS  with 
any  specific  ASSOCIATEDJffiSOURCE  information  from  $OfiJECTIVES  replac- 
ing the  corresponding  generic  information  in  the  RESOURCES.  Since 
it  is  permissable  to  specify  specific  resources  in  both  $PR0CE3S  and 
$OBJECTIVES,  this  module  will  produce  an  error  message  when  incon- 
sistent data  are  Specified.  The  structure  of  $JOBSET  is  shown  in 
Fig.  2. 4. 8-2. 
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Note-  Minimum  (i.e.,  relevant)  portion  ef  required  input  Standard  Data 
Note,  uinimu  v _ ___  structure  will  be  preserved 


Structures  is  shown.  Any 
in  all  trees 


$OBJECTIVES 

Q 


T 

T 

9 


(VALUE) 


OPSEQ 


(NAME) 


TYPE 


$0PSEQ 

Q 

9 


(OPSEQ 

NAME) 


(ELEMENT 


QULtn 

NAME) 


TYPE 


(VALUE) 


DURATION 
(VALUE) 


END 


(VALUE) 


(VALUE) 


Input  Structures  from  Standard  data  Structures  for  Module 

Generation 
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Select  an  OPSEQ  from 
$OBJECTIVES.  (A  first  level 
subnode  of  the  node  labeled 
OPSEQ) 


If  selection  is  an  operations 
sequence  (as  opposed  to  a process) , 
recursively  interrogate  $0PSEQ 
until  a process  is  loacted. 


Assign  a unique  integer  job 
identifier  to  the  next  process 
and  label  a first  level  sub- 
node of  the  output  tree,  $J0BSET , 
with  the  ID 


Add  such  information  as  process 
name,  problem  name,  resources 
associated  with  the  job  (either 
generic  or  specific) , and 
appropriate  Intervals  to  the 
output  tree  (as  shown  for  $J0BSET) 


Are 

'^ther  operation^ 
sequences  on  the 
s.  "pushdown  ^ 


Have 

^all  processes 
been  considered  for 
this  operations 
sequence 


Have 

OPSEQ  ^ 
in  lOBJECTIVES 
been 

“s.  considered^ 


Ygs  Add  appropriate  nodes  to  $J0BSET 
>— O'  to  define  temporal  relations  between 
jobs  and  job  alternatives 


RETURN 
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2. 4. 8. 6 Typical  Application^ 

Since  this  module  merges  some  of  the  information  contained  in 
$0B0ECTIVES  with  all  of  the  required  information  from  $0PSEQ  and 
$PR0CESS,  its  usefulness  is  in  eliminating  numerous  accesses  of 
those  structures  that  result  from  the  information  in  one  tree 
pointing  to  information  in  another.  The  creation  of  jobs  is  a 
logical  first  step  in  building  a schedule.  It  will  be  recognized 
that  if  no  alternatives  or  temporal  relations  appear  in  $00BSET, 
then  $J0BSET  represents  a generic  schedule  unit  that  may  be  given 
a specific  time  assignment.  If,  however,  either  resource  alter- 
natives, job  alternatives,  or  temporal  relations  do  appear  in  the 
problem  specification,  these  alternatives  and  constraints  are  still 
represented  in  $J0BSET,  Thus,  the  initial  creation  of  $J0BSET 
permits  the  subsequent  scheduling  logic  to  deal  with  only 
$OBJECTIVES  and  $J0BSET  without  reference  to  $0PSEQ  or  $PR0CESS. 
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GENERATE  JOBSET 


2. 4. 8. 7 DETAILED  DESIGN 

GENERATE_JOBSEI  builds  the  $ JOBSET  standard  data  structure  by 
iteratively  interrogating  the  input  data  trees  until  the  problem  has 
been  reduced  to  that  of  building  a single  ’JOB  ID'  substructure.  At 
each  level  in  tracing  down  to  this  relatively  simple  problem,  a different 
tree  structure  is  built.  The  trde  structures  at  each  level  are  used  to 
make  up  the  tree  at  the  next  higher  level.  By  using  this  "building 
block"  approach  the  relatively  complex  tree  structure  that  exists  at  the 
highest  level  ($JOBSET)  is  generated  by  dealing  with  its  much  simpler 
component  parts . 

The  "building  block"  tree  structures  generated  and  maintained  by  the 
program  are,  in  order  of  descending  complexity,  $ JOBSET,  $OPSEQ_SET,  $JOBS, 
and  $JOB.  $ JOBSET  is,  of  course,  the  goal  structure  and  will  look  exactly 
as  it  is  shown  in  the  Module  Output  section,  $OPSEQ  SET  and  $JOBS  will, 
in  their  final  form,  look  exactly  like  one  of  the  'SUBNET  ID'  substructures 
of  $JOBSET.  Although  these  two  trees  eventually  assume  the  same  position 
in  $JOBSET,  there  is  a basic  difference  in  what  they  represent.  $OPSEQ  SET 
will  contain  all  of  the  Jobs  contained  in  a given  op-sequence.  Including 
those  arising  from  any  nested  op-sequences.  $JOBS,  on  the  other  hand, 
represents  the  occurrence  of  a single  process.  It  may,  however,  contain 
several  "job"  subnodes  representing  a complete  set  of  possible  job  alternatives, 
only  one  of  which  will  need  to  be  scheduled.  $JOB  is  the  most  basic  structure 
and  is  used  to  build  all  of  the  other  trees  previously  mentioned.  It  looks 
exactly  like  one  of  the  'JOB  ID'  substructures  of  $JOBSET. 
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$JOBSET,  $OPSEQ_SET,  and  $JOBS  are  each  built  by  a separate  PLANS 
procedure.  They  are:  GENERATE_JOBSET  (main  procedure),  SCANjOPSEQJTREE, 

and  MERGE_JOB^INFO , respectively.  The  four  other  Internal  procedures 
operate  at  a lower  level  and  provide  special-purpose  services  to  the  three 
major  procedures  listed  above.  In  several  cases  these  small  procedures 
were  separated  from  the  three  major  ones  in  order  to  make  the  code  more 
efficient.  This  was  accomplished  by  using  a technique  made  possible  by 
PLANS  conventions.  In  several  uses  it  was  necessary  to  frequently  refer- 
ence a subnode  deep  within  a tree.  This  becomes  very  expensive  since  each 
node  reference  requires  a long  list  of  node  qualifiers.  To  eliminate  this 
expense,  a separate  procedure  was  written  which  includes  the  node  reference 
as  an  input  parameter.  The  dummy  tree  name  used  in  the  PROCEDURE  statement 
is  then  effectively  overlayed  at  the  subnode  which  was  passed  in  the  para- 
meter list  of  the  CALL  statement.  This  technique  reduces  the  length  of 
node  references,  Increases  access  efficiency,  and  has  the  added  advantage 
of  prompting  the  PLANS  programmer  to  write  modular  programs. 

In  some  instances,  program  efficiency  was  sacrificed  for  readibility. 
This  is  justified  by  the  fact  that  the  module  will  undoubtedly  need  to  be 
modified,  since  this  code  is  not  Intended  to  be  the  final  version. 

The  sketch  below  shows  the  calling  hierarchy  of  GENERATE_JOBSET  and 
its  seven  internal  procedures.  An  arrow  indicates  a "calling"  relationship 
between  two  procedures. 
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GENERATE  JOBSET 


Calling  relationships  of  GENERATE  JOBSET  and  its  internal  procedures 
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GENE»ATE_JOBSET  (builds  $JOBSET) 


SCAN_OPSKQ_TREE  (builds  $OPSEQ  SET) 


Call  TEMPORAL_RELATIONS_PROCESSOR 
to  replace  generic  process  names 
with  specific  job  identifiers 


f- 


Graft  the  tree  returned  by 
the  last  call  of  this 
procedure  as  the  next 
subnode  of  $OPSEQ  SET 
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(5) 


MERGE_JOB_INFO  (builds  $JOBS) 


^ Is 
^thls  $JOB  \ 
being  built  as  a 
job  alternative 


Create  a $JOB_ALTERNATIVES 
tree  using  information 
from  $OBJECTIVES  or  $OPSEQ 


Select  the  next  subnode 
of  $JOB  ALTERNATIVES 


Call  MERGE_JOB__INFO  with 
this  job  alternative 


On  End 


there  any  Ves 

esource  alternatives^^— 
■V.  to  be  con- 
^'"^s  idered  1^^ 


Call  ENUMERATE_RESOURCE_OPTIONS 
to  generate  Job  nodes  for  all 
possible  resource  combinations 


Insert  $JOB  as  the 
next  subnode  of  $JOBS 


being  built  as  a^'^. 
lob  alternative^x"""^ 


Generate  all  of  the 
JOB_ALTERNATIVES  subnodes  for 
each  job  node  in  $JOBS 


Return 
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ENUMERATE JIESOURCEJDPTIONS  (builds  $COMBINATIONS) 
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TEMPORAL  RELATIONS  PROCESSOR 
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Return 


GENERIC  NAME  ELIMINATOR 
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2. 4. 8. 8 INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 


$COMBINATIONS 

I 

IJIECURSIVE_CALL_  - 

FLAG 

ISAVE 

J 

$JOB 

$JOBS 

$JOB_ALTERNATIVE_SET  - 

$JOB_ALTERNATIVES 

$NAME 

$OPSEQ_NAME 

$OPSEQ_NODE 


used  to  store  a set  of  resource  options  when 
generating  all  possible  resource  combinations 
a global  pointer  used  to  indicate  which  subnode 
of  $OBJECTIVES.  OPSEQ  is  currently  being  processed, 
used  to  indicate  whether  or  not  the  current 
invocation  of  MERGE  JOB  INFO  was  recursive 
used  to  save  the  value  of  the  job  ID  number  of 
the  first  job  node  in  $JOBS 

a pointer  used  to  indicate  which  op-sequence  in 
$OPSEQ  is  the  source  of  the  jobs  currently  being 
generated. 

the  basic  structure  build  by  GENERATE_JOB_SUBSTRUCTURE 
the  final  product  of  a call  to  GENERATE_JOB_SUBSTRUCTURE , 
its  subnodes  formed  by  grafting  on  one  or  more  $JOB 
trees . 

used  to  store  the  specific  job  identifiers  for  a 
complete  set  of  job  alternatives, 
a duplication  of  an  ALTERNATIVES  subnode  of 
$OBJECTIVES  or  $ OPSEQ 

used  to  store  the  substructure  of  an  op-sequence 
whose  elements  have  been  reduced  to  job  nodes, 
used  to  indicate  the  name  of  the  op-sequence  which 
gave  rise  to  the  job  node  currently  being  generated, 
is  the  element  of  $OPSEQ.  (OBJECT_ELEMENT)  that  is 
currently  being  processed. 
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$ACTIVITY 


$ SUBJECTIVITY 
$JOBJNODE 

$RESOURCE_RELATIONS  - 

$RES_REL 

$POINT 

K,  M,  L 
$REIATI0K 
$ SUBNET 


$DUMI 

$DUM2 

$DUM3 

KOBE 


$OBJECT_ELEMENT 

^NILL 


equal  to  $OPSEQ_SET  in  the  case  of  an  opsequence 

equal  to  $NULL  when  processing  a process. 

points  at  the  subnodes  of  $ACTIVITY. 

points  at  the  subnodes  of  $SUB_ACTIVITY,  i.fe.,  the 

$JOB  information. 

a duplication  of  the  RESOURCE JIELATIONS  subnode 
of  $OBJECTIVES  or  $OPSEQ. 

a pointer,  pointing  at  the  subnodes  of  $RESOURCE_ 
RELATIONS 

points  at  the  second  level  down  of  $ACTIVITY, 
the  job  node, 
index  pointers . 

points  at  a subnode  of  $TEMPORAL_NODE . 
duplicates  the  job  node  in  $OPSEQ__SET  if  the 
generic  name  to  be  replaced  is  the  name  of  an 
opsequence. 

temporary  storage  area 
temporary  storage  area 
temporary  storage  area 

used  to  indicate  what  kind  of  input  error  existed 
when  the  call  to  $JOBSET  occurred  (see  section 
2. 4. 8. 9) 

indicates  the  subnode  of  $OBJECTIVES.  OPSEQ  which 
is  currently  being  processed, 
equivalent  to  $NULL. 
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$OPSEQ_SET 

$OPTIONS 


tree  structure  built  by  GENERATE_OPSEQ__SET . 
is  the  RES0U1’.CE_ALTERNATIVES  subnode  of  the  job 
node  which  is  currently  being  built. 


$PROC_NODE 

$PROCESS_ID 

$REF 

$REQUIRED 

$SPECIFICS 

$TEMP 

$TEMP_NODE 
$TEMPORAL_N0DE 
$TEMPORAL_RELATIONS  - 
$TYPE 

$WORKSPACE 


is  the  subnode  of  $PROCESS  corresponding  to  the 
process  for  which  a job  node  is  being  built, 
is  the- subnode  of  $TEMP0RAL_REIATI0NS  whose  value 
is  being  replaced  with  a specific  job  identifier, 
is  the  tree  from  which  $TEMP0RAL_REIATI0NS  will  be 
taken  (either  $OBJECTIVES  or  $OPSEQ) 
is  the  REQUIRED_RESOURCES  subnode  of  the  job  node 
which  is  currently  being  built. 

a duplication  of  an  ASSOCIATED__RESOURCES  subnode 
of  $OBJECTIVES 

used  in  various  places  as  a temporary  storage  area, 
used  to  temporarily  store  a single  subnode  of 
$ JOB_ALTEENATIVE_SET . 

is  the  subnode  of  $TEMP0RAL_REIATI0NS  which  is 
currently  being  processed. 

a duplication  of  a TEMPORAL^REIATIONS  subnode  of 
$OBJECTIVES  OR  $OPSEQ. 

used  to  store  the  name  of  a resource  type 
is  used  as  a storage  area  where  resource  alter- 
natives from  $C0MBINATI0NS  can  be  added  to  the 


$ SOURCE 


resources  in  $REQUIRED. 

the  tree  whose  substructure  will  be  grafted  into 


$TARGET . 

$TARGET  ~ the  tree  onto  which  additional  first- level  subnodes 

will  be  added. 
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$JOBID 

a pointer,  pointing  to  the  job  in  $JOBSET  currently 
being  processed. 

$R_R 

- 

a pointer,  pointing  at  subnodes  of  RESOURCE_RELATION 
substructure. 

$OPJELEMENT 

- 

pointer,  describing  the  substructure  of  $OPSEQ__NODE 

START__TIME 

- 

the  user  specified  start  time  for  a given  job. 

$ DUMMY! 

- 

temporary  storage 

$DUMMY2 

- 

temporary  storage 

$DUMMY3 

- 

temporary  storage 

N 

- 

number  of  subnodes  of  $OPTIONS 
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4.8.9  COMMEMTED  CODE 


GlENERATE^JOBSETi  , 
/•♦♦♦♦•*♦***»*•*♦♦*<***♦*♦***#*«*#«  «>**e***<»*'<**<>^ '»■«'<**■*********•* 

/♦  f/ 
/*  THIS  MODULE  CREATES  INDIVIDUAL  JOBS  FOR  EACH  OCCURRENCE  OF  A */ 
/*  PROCESS  specified  EXPLICITLY  OP  VIA  AN  OPERATIONAL  SEQUENCE  IN  */ 
/♦  SOBJECTIVES,  IT  MERGES  INFORMATION  CONTAINED  IN  SOBJECTiVESi  #/ 
/*  SOPSEOf  AND  SPROCESS  InTO  A TREE  CALLED  $JOBSET«  THE  INTEGER,,  •/ 
/*  VALUE  OF  ♦INITIAL.ID*  IS  USED  TO  CONSTRUCT  UNIQUE  JOB  IDENTIFI-  #> 
/*  ERS  ON  EACH  »JOB  To*  SUBNODE  OF  SJOBSET,  ON  RETURN#  5J0BSET  */ 
/*  Will  contain  the  entire  set  of  jobs  (including  alternatives)  #/ 
/*  which  are  to  be  scheduled,  this  is  the  final  step  before  the  . */ 
/*  decision  algorithms  can  Make  explicit  time  and  resource  assign-  */ 
/*  MENTS.  it  should  re  noted  that  tGENERATE^JOBSET*  ALSO  CHECKS  f/ 
/•  FOR  several  error  CONDITIONS  THAT  MAY  BE  PRESENT  IN  ThE  INPUT  #/ 
/*  DaTa  trees,  AS  A TEMPORARY  WARNING  MECHANISM#  THE  MODULE  RE-,,  */ 
/•  TURNS  AN  ERROR  CODE  TO  THE  CALLING  PROGRAM  VIA  THE  OUTPUT  VaRT-  •/ 
/*  ABLE  »KOOE*,  IN  THE  FUTURE#  COMPLETE  ERROR  MESSAGES  WILL  BE  */ 
/*  WRITTEN  OUT  DESCRIBING  THf  PROBLEM  AND  ITS  PROBABLE  CAUSE.  #/ 


/*  - 
/#*##********«******♦•#*#»*♦****«********<»•»  ***<H»***^^***<**#****<^**<»****/ 

PROCEDURE  (SOBJECTiVES#  SOPSEq#  SPROCESS#  INITIAL^IO#  SJOBSET#  KOOE) 
OPTIONS(EXTERNaL) I 

DECLARE  I#I.RECURSIVE  CALL'^FLAG#ISAVE*SJOB»SJOBS#K#KODE#L#M#n#SNAME# 

SOBJECT>ELEMENT#SOPSEQ„SET»$RELATION#$SPECIEICS# 

START.flME#STEMP«NOnE#STYPE»$WORKSPACE# 

SNILL#  SOPS%I.E#  SJOBIO#  $R«R  LOCALI 
/*  INITIALIZE  variables.  */ 

KOdE  = 0 I label (SJOBSET)  * «0PSEQ»  I I^RECURSI VE«CALL-FLAG  « 0 j 
/♦  SELECT  THE  NEXT  ELEMENT  OF  SOB JECTI VES.OPSEQ  AND  CHECK  TO  SEE  #/ 
/•  IF  IT  IS  AN  OP-SEQUENCE  OR  A SINGLE  PROCESS,  f/ 

/*  This  loop  iterates  across  the  first-level  subnodes  of  sobjec-  •/ 
/♦  TIVES.OPSEO  • on  each  successive  iteration  it  generates  A •/ 
/*  'SUBNET  ID*  SUBNOOE  IN  SJOBSET  WHICH  BECOMES  A FATHfR  NODE  TO  f/ 
/*  all  OF  ITS  DESCENDENT  JOB  NODES,  #/ 

DO  FOR  ALL  SUBNOOES  OF  SOBJECTIVES. OPSEQ  USING  SOBJECT.ELEMENT  t 
IF  sobject_element,type  » »0PSEQ» 

THEN  IF  SOPSEQ,«LABEl(SOBJECtLELEMENT)  (1 ) IDENTICAL  TO  SNUl  L 

Then  do  i kode  = 2 j return  i end  » 
else  do  I 


/*  CALL  *GENERATE..0PSEQ_SET»  WITH  THIS  OP-SEQUENCE  AND  THEN  SRaFT  */ 

/*  sopseqIset  at  the  next  'Subnet  id*  node  of  sjobset.  ♦/ 

call  gemeratfIopseo^set 

($OpSEQ.#LABEL($OBJECT»ELEMENT) #S0PSEQ_SFT)  t 
call  TEmP0RAL«RELATI0NS_PR0CESS0R 

($0PSEQ^SET#S0PSFQ)  t 
graft  SoPSEolSET  AT  SJOBSET (NEXT)  I 
LABEL($J0BSET(LAST) ) K label (SOBJECtLelEMENT)  I 
END  ? 

ELSE  IF  SoBJECT^ELEMfNT.TYPE  'PROCESS' 

Then  do  * kode  = 3 » return  i end  i 

ELSE  IF  SPROCESS. WLABEL(S0BJECT„ELEMENT) 


2.4.8-22 
Rev  C 


ORIGINAL  PAGES  B 
OF  POOR  QUALiry 


/♦ 


IDENTICAL  TO 
RETURN  I END  » 


♦ / 
♦ > 


*NUi*i 

THEN  DO  I KODE  ■ 1 ^ 
else  do  I 

CALL  .6ENERATE1JOb1SUBSTRuCTURE<  ‘'VmJS  SSnl  OF  SJOBSET 

and  THEN  6RAFT  $JOBS  AT  ThE  NEXT  .SUBNET  ID'  NODE  OF  SJOBSET. 

SNlLL  * SNULLI 

CALL  GENERATE.JOB.SUBSTRUCTURE ( SNILL . 

SPROCESS.#LABEL(SOBJEcT.ELEMENT) * 

SNILL) I ^ ^ 

graft  SjoBS  AT  SJOBSET (NEXT)  I 

END  I 

/.  CALr-TEMPORAL_RELATIONS_PROCESSOR.  TO  REPLACE  SENERIC  PROCESS 

/•  names  with  specific  job  ^OENTIFIERS.  icrTTVES)  i 

CALL  TEMPORAL.RELATIONS_PRoCESSOR($JOBSET*SOBJECTIVES)  I 

JoVor’aLL  SUBNOOES  of  SOBJECTIVES.OPSEQ  USING  SOBJECT.ELEHENT  I 

iF*$OBjECT:^ELEMENT.SUBNETllD  IDENTICAL  TO  SNULL 

THEN  LABEL(SJOBSET(I)l  = I ♦ 2:1*1, Lir„T  SUBNET  IB  I 
Cl  cc  i ARFi  (SlOBSETdi)  * sOBjECT,„ELEMENT*SUBNtT  ID  I 

IF  loljEC?:lt;E5ES?:REs8iRCE:RELATlON, FIRST)  NOT  IDENTICAL  TO 
SNULL 

FOR  ALL  SUBNODES  OF  SJOBSET(I)  USING  SJOBlDI  ^ . 

DO  FOR  ALL  SUBNOOES  OF  SOB JECT^ELEMEnT.RESOURCElRELATION 

insert  SR^R  before  SJ0BID*RES0URCE,.RELAT10N(FIRST) I 
END  I 
END» 

END  I 
END  t 

return-error^cooe*  return  I 


*/ 


Tuncp  adtSTma  PROM  ANY  NESTED  OP*SF®UENCES«  THE  ONLY  ^ 

rOp|lorNODirir?HE‘FlRST!LkL  SUBST^  OF  *OPSEO  CORRES- 

/*  ponding  to  the  opse(3  for  which  sopseq^set  is  to  be  built. 

/.  °LABEL^T5rSoJT*So5l'’oF^MPSEQ^SET  WITH  THE  NAME  OF  THIS  OPSEO. 

/*  ^select*^the^nexVelf.m^  ^”^^~®^’?f^process^'^ 

/♦  IT  is  another  op-sequence  or  a single  I 

do  for  all  subnodes  of  sopseq^node  using  SOPjELEMENT  I 

IF  SOP..ELEMENT.TYPE  « ’PROCESS* 
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*> 

*/ 

*/ 
♦ / 

*/ 

*/ 
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/# 

/* 


THEN  IF  $PROCESSo^^LAbEL<SOP„ELE-M£NT?  IDENTICAL  TO  SNULL 

then  do  8 KOOE  « 4 ? 60  TO  RETURN.ERROR^COOE  I END 8 

CALL  »GENERATE.J0B„SUBSTRUCTURF»  with  this  PROCESe  , fi 

AND  THEN  GRAFT  SJOBS  AT  ThE  NEXT  «SDBmET  ID*  NODE  OF  S0PSEQ_SET*  */ 

Else  do  i 

STEMP*  LABfL  (SOPSEQ:.NODE)  I 

call  6ENER6TE^J08„SU8STRUCTURE($TEMP. 

$PR0CES5.##LABEL  (SOP^ELEMENT)  * 
*0P_ELEMENT) I 

ppune  STEMPI 

Graft  sjobs  at  $opseq,.set(next)  i 

END  I 

ELSE  IF  SOP-.ELEMENT»tVPE  soPSEQ*  . 

Then  do  8 kode  * 6 * go  to  return_error_cooe  » 

ELSE  IF  S0PSFQ.#LABEL(S0P1eLEMENT) (FIRST) 

IDENTICAL  To 

then  do  ? KOOE  * 5 8 

GO  TO  R£TURN_ERR0R«.C00E  8 

END  8 
ELSE  DO  8 

/*  CALL  *GENERaTE10PSEQ«SET*  WITH  THIS  OP-SEQUENCE  AND  THEN  CALL 
/*  * TEMPORAL-RELATIONS^PROCEfSOR*  to  replace  the  GENERIC  PROCESS 

/•  NAMES  WITH  SPECIFIC  JOB  IDENTIFIERS. 

CALL  geneRate_opseq_set 

($0PSEO.WLABEL(SOP«ELEmENT) »STEmP) 

CALL  temporal_relations.processor 

($TEMP*S0PSFQ)  8 


end  8 

«NUiV 


*/ 

*/ 

*/ 

8 


/* 

/♦ 


END 


GRAFT  THE  TREE  RETURNED  By  THE  LAST  CALL  OF  THIS  PROCEDURE  AS 

THE  NEXT  SUBNOOE  OF  SOPSEo^SET. 

GRAFT  STEMP  AT  SOPSEQ_SET (NEXT ) 8 

END  I 

END  I 

6ENERATE_0PSEQ...SET  8 


*/ 

#/ 


GENERATE  JOB  SUBSTRUCTURES 

/♦  THIS^PROCEDURE  builds  the  SJOBS  tree  STRUCTURE  REPRESENTING  THF 
OCCURRENCE  OF  A SINGLE  PROCESS  OR  ONE  OF  ITS  ALTERNATIVES. 
S0PSE<3^NAME  IS  AN  INPUT  TREE  WHOSE  VALUE  IS  THE  NAME  OF  THE  OP- 
SEQUENCE  TO  WwlCH  THE  CURRENT  JOB  BELONGS,  SPROC.NODE  I*S  THE 
FIRST-LEVEL  SUBSTRUCTURE  OF  SPPOCESS  CORRESPONDING  TO  THE 
PROCESS  FOR  WHICH  SJOBS  IS  TO  BE  BUILT, 
procedure  (SOPSEQ^NAME*  $PROC|;jNODE«  $OPS„£LE)  RECURSIVE  8 
DECLARE  SALTernaTI VEs  SCOMBINaTIONSsSJOB^ALTERNATIVES* 

$J08„ALTERNATiVE«SET»$0PTI0N»S0PTI0NS**RE0UIRED, 

SOUMMYl?  SDUMmY?  LOCAL  8 

/*  DUPLICATE  The  appropriate  node  in  sPROCESS  as  sjob  and  assign  a 
/•  UNIQUE  JOB  ID.  number  TO  THIS  J0B« 


/♦ 

/* 

/♦ 

/* 

/* 


#/ 

*/ 

#/ 

#/ 

'*/ 


*/ 

#/ 
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$JOB  ■ SPROCJ^ODE  I 

SJOB, PROCESS  ■ label (SJOB)  I 

LA«EL(SJOB)  « INITIAL.10  I INITIA^lID  « INITIAL.ID  ♦ 1 « - 

/♦  IF  NEEOEOt  create  *J0B«TYPF«*  t J0B_INTERVAL* * » PROBLEM^NAME • * anD  */ 
/*  'OPSEQ*  NODES  IN  SJOB  WITH  APPROPRIATE  SUBSTRUCTURE  AND  VALUES.  ♦/ 
IF  SjOB.PROCESSlTYPE  NOT  IDENTICAL  TO  SNULL 
THEN  LABEL {SJOB, PR0CESS|TYPE)  = •JOB.TYPE*  I 
IF  SJOB. DURATION  IDENTICAL  TO  SNULL 

then  do  I KODE  s 7 I GO  TO  RETURN^ERROR^CODE  I END  I 
START.TIME  = INFINITY  I 

IF  $OBJECT«ELEMENT,SChEDULF«TIME. start  not  IDENTICAL  TO  SNULL 
THEN  IF  $OPSEO«NAME  IDENTICAL  TO  SNULL 

Then  start^time  « sobject-Element.schedule^time. start  i 

else  do* 

LABEL (SDUMMYl)  * $OBJEcT_ELEMENT*SCHEDULE.TIME.PROCESS«NaMEI 
label (SDUMMY2)  = SJOB.PROCESSI 
IF  LABEL(SDUMMY1)=  label (SDUMMYH) 

then  STaRT_TIME  s SORJECT-ElEMENT.SCHEDULE^TIME. start  I 

end* 

else  I 

IF  start.time  -*  infinity 

Then  do  i sjob.job.inTfrval, start  = start.time  * 

SJOB, JOB«INTfRVAL. end  * START^TIME  ♦ SJOB, duration  I 

END  I 

IF  SoBJECTIVES.PROBLEMJ^AMf  not  identical  to  SNULL 
then  SJOB.pROBLEM.NAME  ■ SOBJECTI VES.PROBLEM.NAME  I 

IF  sopseq^name  not  identical  to  snull 
then  sjob.opseq  = S0PSE0_NAME  I 

/*  IF  THERE  ARE  RESOURCE  ALTERNATIVES  TO  BE  CONSIDERED*  CALL  ♦/ 

/•  »ENUMERATE«RESoURCE_OPTIOn(S»  to  generate  JOB  NODES  FOR  ALL  */ 

/•  possible  resource  combinations,  otherwise*  INSERT  SJOB  AS  THE  ♦/ 
/*  NEXT  SUBNODE  OF  SjOBS. 

IF  SJOB, RESOUPGE.J^LTERNATIvE (FIRST)  IDENTICAL  TO  SNULL 

Then  IF  i recursive«call«flao  * o 

then  graft  Insert  sjob  before  sjobs(firsT) i 
else  graft  sjob  at  SJOBS (NEXT)  * 

ELSE  DO  * K » 1 * INITIAL.ID  ■ INITIAL«ID  • I I 
graft  SjOB. RESOURCE  AT  SREQUlRED  I 
GRAFT  SJOB.RESOURCf«ALTERNATIVE  AT  SOPTIONS  I 
N * NUMBER (SOPTIONS)  * ^ 

CALL  ENUMERATEJ^ESoURCE^OPTIONS  | 

PRUNE  SjOB*SREQUIREO*$OPTIONS*SWORKSPACE*SCOMBINATIONS  I 
END  I 

/♦  IF  THIS  SJOB  IS  BEING  BUIlT  AS  A JOB  ALTERNATIVE*  RETURN,  */ 

/*  OTHERWiSEt  CREATE  A $ JOB^ALTERNAT I VES  TREE  USING  INFORMATION  */ 

/♦  FROM  SOBJECTIVeS  OR  SOPSEo, 

IF  r RECURSIVE-CALL_FLAG  -*«  0 THEN  DO* 
i.recursive.calL^flag  = 0 » 

RETURN* 

END* 

IF  S0PSE(3..NAME  identical  TO  SNULL 
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then  if  SOBJECT^ELEMENT. alternative (FIRST)  NOT  IDENTICAL  TO  fNUi  L 

Then  sjob.alternatives  ■ sobject^element. alternative  i 
else  I ... 

else  if  S0RS|ELE«  ALTfRNATIVE(FIRST)  not  identical  to  snui  l 
Then  sjob.alternatives  » sops.ele.  alternative  i 
IF  sjobIalternatives  not  identical  to  snull 
then  doi 

/*  select  the  next  subnode  of  $job_aljernatives.  */ 

do  for  all  subnodes  of  Sj08i»ALTERNATIVES  USING  SALTERNATIVE? 
I_REcURSlVE.CALL-FLA6al I 

IF  SPR0CESS.#(S«LTERNATIVE)  identical  to  s^ull 

Then  do  » kode  » 9 i go  to  return^errorlcode  i enoi 
Else  call  generate.job-SUbstructure($opseo«name* 

$PR0CESS.#(SALTERNATIVF) # 
SOPS.ELE) I 

END  I 

PRUNE  SJ0B_ALTERNATIVES  I 

/•  SJOBS  NOW  contains  A COMPLETE  SET  oF  JOB  ALTERNATIVES,  GENERATE  #/ 
/*  ALL  * JOB_ALTERNATlVES»  SUrNOOES  FOR  EACH  JOB  NODE  IN  SJOBS,  #/ 

PRUNE  $J0B_ALTERNATIVE«SET  I ISAVE  * LABEL(SJ0BS(FIRST) ) I 
DO  KalSAVE  TO  InITIAL«ID-1  I 

SJOB_ALTERNATIVE_SET(NExT)  ■ K I 

End  I 

DO  K«1  TO  INITIaL.ID-ISaVE  I 

GRAFT  SJOB^ALTERNATIVE^SET (FIRST)  AT  STEMP^NOOE  » 

SJOBS (K) .jobIalternativf  = SJOBIaLTERNATIVE^SET  I 
graft  STEMP-NODE  at  SJOr_ALTFRNATIVE.SET(NEXT)  j 
END  I 

END  I 


ENUMERATE«RES0URCE_0PTI0NS»  PROCEDURE  RECURSIVE  I 

/*  This  procedure  generates  a sjop  tree  structure  for  every  pos-  , ♦/ 

/*  SIBLE  combination  OF  RESOURCE  ALTERNATIVES,  IT  CALLS  ITSELF  RF*  */ 
/*  CURSIVELYt  ONCE  FOR  EACH  FIrST-LEVEL  SUBNODE  OF  SOPTIONS.  #/ 

/*  #/ 
/♦  SELECT  A NEW  RESOURCE  ALTERNATIVE  FROM  THE  NEXT  SET  OF  OPTIONS."  */ 
/♦  ADO  IT  TO  SCOMbINATIONS  AmD  CHFCK  TO  SEE  IF  SCOMBINATIONS  NOW  */ 
/#  CONTAINS  ONE  ALTERNATIVE  FROM  EACH  SET  OF  OPTIONS,  */ 


DECLARE  SOPTION  LOCAL! 

DO  FOR  ALL  SUBNODES  OF  SOPTIONS(K)  uSInG  SOPTION  I 
SCOMBINATIONS(K)  = SOPTtON  I 
IF  K N 

THEN  DO  ! K « K4l  I CALL  ENUMErATE^RESOURCE.OPTIONS  | 

K=K-ll  END! 

/*  add  this  set  Of  alternatives  to  the  Original  #/ 

/*  ♦REOUIRED.RESOURCES»  NODE  OF  SJOB,  */ 

ELSE  DO  ! SWORKSPACF  » SREQUIRED  I 
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DO  FOR  ALL  SUBNODES  OF  SCOMBlNATIONS  USING  SSELECTION  I 
DO  FOR  ALL  SuBNODES  OF  SSELECTION  USING  STYPE  I 

IF  $workSpace.#labeL(stype)  identical  to  SNUI  L 

THEN  SWORKSPACE(NEXT)  * STYPE  I 
ELSE  Do  FOR  ALL  SUBNODES  OF  STYPE  USING  SNAME  I 
SWORKSPACE.#LABEL(STYP«t>  (NeXT)  * SNAME  I 
END  I 

END  I 
END  I 

graft  sworkspacf  at  s job, resource  I 

/*  ASSIGN  A UNIOUF  JOB  ID.  NUMBER  TO  THIS  "NEW**  SJOB  AND  DUPLICATE  ♦/ 
/#  IT  AS  THE  next  SUBNOOE  OF  SjOBS_. 

LAREl(SJOB)  * InITIAL.ID  * 

SJOBS(NEXT)  « SjOB  I. 

iniTialIid  * inttial_id  ♦ 1 I 

END  I 

END  I , 

end  enumerate^resource^options  « 

END  6ENERATE_v)0B.SUBSTRUCTURE  % 


/• 

/• 

/• 

/♦ 


/♦ 

/♦ 


/* 

/• 

/* 


• / 

*/ 

• / 

'•/ 


• / 

♦ > 


temporal  RELATIONS^PROCESSORJ  procedure  (SACTIVITY.  SREF)  » 

/*  THis'PROCEDURE  CONTAINS  ThE  EXECUTIVE  LOGIC  WHICH  REPEATATI VELY 
BUILDS  AND  SCANS  STEMPORAl_RELATIONS*  ONCE  FOR  EACH  FIRST-LEVEl 
SUBNOOE  OF  THE  INPUT  PARAmETERi  SACTIVITY,  SREF  IDENTIFIES  THF 
REFERENCE  TREE  FROM  WHICH  THE  • TEMPORAL^RELATIONS • SUBNODE  IS  TO 
BE  TAKEN  WHEN  CREATING  STfMPORAL^RELATIONS#  . ■ . 

DECLARE  SJOB  nOoE.SSUB.ACTi VlTy ,STEMP*STEMP0RAL«RELATI0NS  LOCAL  » 
DECLARE  SRESOURCE.RELATIONS*  SRES^REL*  SPOINT  LOCALI 

s Q ^ * »■*— 

SELECT  THE  NEXT  SUBNOOE  OF  THE  INPUT  TREE  (SACTIVITY)  AND  BUlLO 
A STEMP0RAL_RELATI0NS  tree  containing  UNK3UE  JOB  IDENTIFIERS, 

DO  FOR  ALL  SUBNODES  OF  SACTIVITY  UJiNG  SSU8_ACTI VITY  ; 

$TEMPORAL_RELATIONSsSREf.#LABEL (SACTIVITY)  (K) ,TEMPORAl — RELATTONi _ 
THESE  THREE  STATEMENTS  CAiL  * GFNERIC^NAME^ELIMINAtOR • FOR  EACH^  f/ 
•PREOECESSORi t »SUCCESSOR«*  AND  ’GENERAL*  SUBNODE  OF  STEMPORAL- 

rflations.  any  Other  subnodes  of  this  tree  are  ignored,  . . */ 

CALL  GENERIC” NAME.ELIMINATOR ( STEMPORAL^RELATIONS, PREDECESSOR) I 
CALL  GENERIC^NAME_ELIM1NAT0R($TEMP0RAL.RELATI0NS, SUCCESSOR)  I 
CALL  GENERICInAME_ELiMINATOR(STEMPORAL«RELATIONS, GENERAL)  » 

IF  LABEL (SSUB.ACTIVITY)  * 

Then  do  For  all  subnodes  of  ssub^activity  using  sjobjmode  » 

IF  STEMPORAL-RELATiONS (FIRST)  IDENTICAL  TO  SNULL 
then  SjOB1_NODE,TEmPORAL.RELATION  a STEMPORAL-RELATIONS  » 

End  T , . 

/♦  COMBINE  STEMPORAL1.RELATIOnS  WITH  THE  TEMPORAL  RELATIONS  INFO  OF 
/♦  THE  DESCENDENT  JOBS  OF  THIS  SUBNODE. 


f 
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ELSE  DO  FOR  ALL  SUBNODES  OF  SSUB„ACTI VITY  USING  SJOB.NOOE  I 
IF  STEMPORaL-RELATxONS {FIRST)  »•  IDENTICAL  TO  SNULL 
Then  doi 

Call  genepatf_subnodes(stemporal-RELations, 

PREDECESSOR »SJOb"^  NODE* TEMP0RAL„RELAT ION, PREDECESSOR) I 

Call  generate-SUbnodes(stemporal-RELations, successor, 

SJOBInodE.TEMPORAI relation, SUCCESSOR)  I 

Call  generatf«subnodes<stemporai ^relations.generaI.’* 

SJOB.NODE,TEMPORAL„RELATION, GENERAL)  I 

END! 

FND  I 

END  I ^ . 

/•  MERGE  ALL  OF  THE  DESCENDEmT  JOB  NODES  UPWARDS*  ELIMINATING  ALL  •/ 
/*  OF  THE  first-level  SUBNODeS  OF  SACTIVITY,  */ 

IF  SREF  NOT  identical  TO  SOBJFCTIVES 

then  do  » 

LABEL(*TEMP)  ■ LABfL(SACTIVITY) I 
do  L«nUmBER($ACTIVtTY)  to  1 by  -1  I 
prune  jresourceIrelationsi 

SRESOURCE_RELATiONS  » $REF,#LABEL(SACTIVITY) (L) .RESOURCE^RELATIoNI 
IF  SRES0URCE_RELATI0NS (FIRST)  NOT  IDENTICAL  TO  SNULL 
then  DOI 

DO  FOR  all  SUBNOOES  OF  SRESOURCE-RELATIONS  USING  SRES.RELI 
DO  FOR  ALL  SUBNODES  oF  SaCTIVITY(L)  USING  SPOINTI 

INSERT  SREsIrEL  BEFORE  SP0INT,RES0URCE*RELATI0N (FIRST) I 
END  I 
END! 

end  I 

IF  LABEL(SACTIVITY(L) ) -a  «» 

THEN  DO? 

DO  MsNUMBER($ACTlVITY(Lj j TO  1 BY  -I? 

GRAFT  insert  SaCTIVT TY (L) (M)  BEFORE  STEMP (FIRST) | 

End; 

END? 

ELSE  DO? 

DO  MsNUmRER(SACtIVITY(L) ) TO  1 BY  -I  ? 

GRAFT  insert  SACTIVITY(L) (M)  BEFORE  STEMP (FIRST) ? 

END  ? 

END? 

end  ? 

GRAFT  STEMP  AT  SACjIVlTY  I 
END  ? 


GENERATE.SUBN0DES«  procedure  (SSOURCE.  STARGET)  I 

/*  THIS  PROCEDURE  DUPLICATES  THE  SUBNODES  OF  SSOURCE  AS  SUBNODES  oF  * 
/*  STARGET  BY  »INSERT»-IN6  EaCH  ONE  (WITH  ITS  SUBSTRUCTURE)  BEFORE  f 
/♦  TwE  FIRST  SUBNODE  OF  STaRgET*  ONE  LEVEL  BELOW  THE  ROOT  NODE,  • 


2.4.8-28 
Rev  C 


tV  ViV 


IP  SSOURCE (FIRST)  IDENTICAL  TO  SNULL  K.  STARGET (FIRST)  IDENTICAL  TO 

snulL 

THEN  001 

P«UNE  SSOURCE I 
PRUNE  STARQETi 
RETURNI 
ENO» 

DO  M*NUMBER( SSOURCE)  TO  1 RY  -1  I 

INSERT  SSOURCE(M)  BEFORE  STARGET (FIRSTM 
END  I 

END  6ENERATE.SUBN00ES  | 


generic.name_elimInator*  procedurf  (stemporalInode)  » 

/♦  THIS  procedure  IS  responsible  for  eliminating  the  generic  »/ 
/♦  process  or  OPSeQ  names  TH&T  appear  below  STEMPORALINODE  BY  »/ 
/*  REPLACING  them  WITH  SPECIFIC  JOB  IDENTIFIERS*  $TEMPORaL„NODE  #/ 
/*  yiLL  always  be  one  of  the  THREE  STANDARD  SUBNODES  OF  STEMPORAL^  #/ 
/♦  RELATIONS!  •PREDECESSOR* ♦ »SUCCESSOR«*  OR  »GENERAL**  «/ 


DECLARE  SSUBNET#  SOUMl#  SDliM?,  SSUB,  L LOCAL! 

IF  stemporal_nodE(first)  Identical  to  snull 
then  doi 

PRUNE  stemporalInode I 

RETURNI 
END  I 

00  L = NUMBER (STEMPORAL.NOdE)  TO  1 RY  -1| 
define  SRELATION  as  STEMPoRALInoDE(L) I 
IF  LABEL (STEMPORALINODE)  e iGENERAL* 

then  define  SPROCESS-ID  as  SRELATI0N(4)  I 
ELSE  DEFINE  SPROCESS^.ID  AS  SRELATION  I 
SSUBNET  * SACTIVITY(FIRSTT  (LABEL ( sELEMENT ) * SPROCESS^ ID) ) | 

/*  IS  THE  GENERIC  NAME  TO  BE  REPLACED  THE  NAME  OF  A PROCESS?  ♦/ 

IF  SSUBNET  identical  To  SNULL 
THEN  DO  I 

DO  FOR  ALL  SUBNoOES  OF  SACTIVITY  USING  SSUBi 

/•  replace  the  generic  Name  with  the  job  id.  number  corresponding  «/ 
/*  TO  this  process.  it/ 

Label (SDUMi)  » sprocess.ioi 
LA8EL(SDUM2)  a SSUB (FIRST) .PROCESSI 
IF  LABEL (SDUmI)  = LABEL (S0UM2) 

Then  do  i 

SPROcESSLiD  = LABEL($SUB(FIRST) M 
60  To  NEXTInoDEI 

end  I 

END  I 

KODE  = 10  I go  to  RETURN-ERR0R„C0DE  I 

end  I 

/*  determine  the  job  id.  number  of  each  job  in  this  op-seouence  */ 
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/•  AND  generate  NEW  TEMPORAL  RELATIONS  SUBNODES  WITH  THE  #/ 

/•  CORRESPONDING  JOB  ID.  NUMBERS  AS  THEIR  VALUES,  i/ 

ELSE  DO  I 

IF  Label  (STEMPOPAL.NOOE)  -»■  'GENERAL* 

Then  do  for  all  subnooes  of  ssubnet  using  sjob'inodE  i 
$TEMpORALfNODE<NEXT)  » LABEL ($ JOB  NODeF  I ' 

END  I 

ELSE  DO  FOR  ALL  ^UBNOOES  OF  SSUBNET  USING  SJOB-NODE  i 
SPROCESSHIO  > LABEL ($JOB.NODE^  I 
STEMpOPAL_NODE(NEXT)  = SRELATION  l 
END  I 

prune  SRFLATiON  I 
END  I 

NEXT.NODE* 

END  t 

end  generic_name_eliminator  I 
END  TEMPORAL.RELATiONs1pROCESsOR  | 

END  GENERATE_JOBSET  I 
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2.4.8.11  COMMENTS  ON  FUTURE  MODIFICATIONS 


In  its  present  form  GENERATE_JOBSET  provides  many  useful  services 
to  the  PLANS  programmer.  Below  is  a discussion  of  some  needed  changes 
and  possible  extensions  of  its  scope  that  will  make  it  an  even  more 
powerful  module . 

It  would  be  desirable  to  compact  the  code  of  this  module  by  com- 
bining the  main  procedure  (GENERATE_JOBSET ) with  the  internal  procedure 
called  SCAN_OPSEQ_TREE.  Since  the  logic  of  these  two  modules  is 
functionally  similar,  it  appears  that  this  change  could  be  accomplished 
without  too  much  difficulty.  The  major  problem  in  combining  the  two 
procedures  arises  from  the  fact  that  one  of  them  is  recursive. 

Another  needed  change  to  this  module  is  to  include  processing  of 
the  Information  found  below  the  RE  SOURCE  SjGENERATED  and  RESOURCESJDELETED 
nodes  of  $PROCESS.  All  of  the  resource  data  for  a given  job  should  be 
available  beneath  the  RESOURCE  node  of  $JOBSET . This  allows  for 
easier  access  of  information  by  NEXTSET  and  several  other  modules. 

Also  of  major  Importance  is  a problem  with  the  "brute-force"  method 
that  has  been  used  to  resolve  temporal  relations  with  an  op-sequence. 
Presently,  if  a job  is  encountered  that  has  an  op-sequence  as  its  predecessor, 
GENERATE_JOBSET  simply  lists  all  of  the  jobs  contained  in  the  op-sequence  as 
Its  predecessors.  Although  this  method  is  functionally  sufficient,  it  is 
unsatisfactory  since  it  results  in  the  generation  of  many  unneeded  nodes. 

It  may  be  necessary  to  call  REDUNDANT_PREDECESSOR__ CHECKER,  PREDECESSOR_ 
SET__INVERIER,  and/or  ORDER_BY_PREDECESSORS  in  order  to  alleviate  this 
problem. 
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Another  tnuch-nceded  change  is  to  provide  GENERATE_JOBSET  with  some 
additional  logic  to  recognize  a process  or  opseq  name  for  which  it  has 
already  built  appropriate  structures  in  $JOBSET.  When  such  a reoccurrlng 
activity  is  encountered  its  JOB  ID  nodes  can  be  built  simply  by  duplicating 
the  previously  generated  nodes  and  making  some  minor  changes.  This  change 
would  greatly  increase  the  efficiency  of  the  module,  despite  the  fact 
that  it  will  lengthen  the  code. 

Currently,  GENERATE_JOBSET  creates  $JOBSET  so  that  its  first-level 
substructure  is  identical  to  that  of  $OBJECTIVES. OPSEQ.  That  is,  each 
SUBNET  ID  node  corresponds  directly  to  a first-level  subnode  of 
$OBJECT IVES. OPSEQ.  All  of  the  descendent  job  nodes  will  be  located  one 
level  below  the  SUBNET  ID  node.  This  approach  was  used  mainly  because 
it  greatly  simplifies  the  logic  of  the  TEMPORAL_RELATIONS_PROCESSOR  pro- 
cedure. A possible  alternative  approach  is  to  create  a new  SUBNET  ID 
node  for  each  op-sequence  encountered . This  would  require  some  extra  logic 
to  process  nested  op-sequences,  but  it  would  insure  that  each  job  would 
appear  in  $JOBSET  as  a direct  descendent  of  its  "father"  op-sequence. 

Again,  the  major  drawback  of  this  approach  is  the  difficulty  it  creates  in 
resolving  temporal  relations.  However,  it  allows  for  a greater  degree  of 
problem  decomposition  by  the  project  scheduling  modules.  This  would  facilitate 
a more  e^fficient  solution  of  the  scheduling  problem. 

Some  possible  changes  of  questionable  desirability  are  listed  below. 

At  this  point,  it  has  been  determined  that  more  time  and  data  are  needed 
to  properly  assess  their  usefulness  and  feasibility. 
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(1)  allow  the  user  to  specify  the  number  of  JOB  ID  nodes  to  be 
generated 

(2)  (contingent  on  #1)  provide  the  restart  capability  needed  in 
order  to  allow  the  user  to  input  a partially  built  $JOBSET. 

(3)  write  out  a warning  message  if  a generic  resource  is  en- 
countered in  $OBJECTIVES.ASSOCIATED_RESOURCES 

(4)  allow  the  user  to  specify  alternative  op-sequences  in  $OPSEQ 
and/or  $OBJECTIVES. 
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2.4.9  EXTERNAL_TEMP_RELATlONS 


2.4.9  EXTERNAL_TEMP_RELAT  IONS 

2. 4. 9.1  Purpose  and  Scope 

This  module  will  determine  the  temporal  relations  specified 
for  the  jobs  under  a single  subnode  of  $JOBSET  which  will  be 
violated  by  merging  two  partial  schedules  each  of  which  consists 
of  one  or  more  schedule  units  (jobs).  This  single  subnode  and 
its  substructure  will  be  passed  through  the  argument  list  as 
$ SUBNET . 

This  module  will  identify  violations  of  temporal  relatior?'^ 
that  result  from  the  association  of  the  two  partial  schedules. 

It  is  not  necessary  that  either  or  both  partial  schedules  be 
free  of  internal  temporal  constraint  violations;  if  such  violatxons 
are  present  however,  they  will  not  be  detected  by  this  module 
unless  a violation  results  from  the  association  of  a job  in  the 
first  partial  schedule  with  one  or  more  jobs  in  the  second  partial 
schedule.  It  is  thus  possible  to  call  the  module  with  partial 

schedules  that  are  temporally  infeasible. 

The  module  will  build  an  output  tree  containing  a first-level 
node  for  each  identified  violation  of  a temporal  relation.  If  re- 
dundant temporal  relations  are  specified  in  $JOBSET  then  redundant 
nodes  will  appear  in  the  output  tree,  (e.g.,  A<B,  B>A  is  a re- 
dundant specification).  For  each  such  node  the  identifiers  of  the 
conflicting  jobs,  the  respective  job  intervals,  and  the  violated 
temporal  relation  will  be  recorded. 

2. 4. 9. 2 Modules  Called 

ELEMENTARY_TEMP_RELATION S 

2.4. 9-1 
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2. 4. 9. 3 Module  Input 

This  module  will  be  called  with  four  arguments.  -There  are  three 
input  arguments;  $SUBNET,  $SCHEDl,  and  $SCHED2.  The  structure  of 
$SUBNET  is  identical  to  a single,  first-level  subnode  of  the  structure 
output  from  the  module  GENERAlTE_JOBSET  . 

The  structure  of  the  two  partial  schedules  to  be  examined  for 
temporal  constraint  consistency  have  the  standard  schedule  unit  (job) 
structure,  and  are  equivalent  to  first-level  subnodes  of  $SCHEDUI£. 

The  minimum  data  structures  required  from  the  standard  structures 

I 

$SUBNET,  $SCHED1,  and  $SGHED2  are  shown  in  Fig-  2.4. 9-1.  Note  that  in 
the  minimum  structure  the  fifth  and  sixth  subnodes  of  a relation  in  the 
TEMPORAL_^RELA.TION  substructure  are  not  mandatory  in  every  case. 

2. 4. 9. 4 Module  Output 

This  module  will  build  and  return  an  output  tree  with  the  structure 
shown  on  the  following  page. 

Each  node  of  $TEMPOBAL__VIOLATION  will  correspond  to  a violation 
of  a temporal  relation  in  $SUBNET  (input)  that  results  only  from  the 
association  of  $SGHEDl  and  $SCHED2. 
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OUTPUT  DATA  STRUCTURE 


STEMPORALJIOLATION 


pc 

(D 


< 


NJ 

• 

vO 

I 

U) 


o 


Note:  Minimum  (i.e.,  relevant)  portion  of  the  required  input  standard 

structures  is  shown.  In  all  trees,  any  additional  structure  will  be 
preserved.  

$ SUBNET 


$SCHED1  $SCHED2 


(VALUE)  (VALUE)  (VALUE)  (VALUE) 

Fig.  2. 4. 9-1  ^ , 

Minimum  Required  Input  Structures  from  Standard  Data  Structures  for  Module: 

EXTERNAL_TEMP_REIAT  IONS 
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2. 4. 9. 5 Functional  Block  Diagram 


2. 4. 9-5 


2. 4. 9-6 


2. A. 9. 6 Detailed  Design 


From  each  of  the  two  partial  schedules  a single  Job  is  taken.  One 
job  is  selected  and  examined  to  see  if  the  other  job  is  a predecessor, 
successor,  or  generally  related  temporally  to  the  first.  If  not  the  other 
job  is  selected  and  examined.  When  a temporal  relationship  is  identified, 
the  module  ELEMENTARY_TEMP_REIATION  is  called  to  determine  the  satis- 
faction of  the  relationship.  If  the  relationship  is  not  satisfied  a node 
is  built  to  Identify  the  temporal  violation.  The  other  job  is  then 
selected  or  examined,  or  another  job  pair  la  identified  and  the  procedure 
repeated  until  all  job  pairs  have  been  checked. 

2. A. 9. 7 Internal  Variable  and  Tree  Names 
I,  J,  K - index  pointers 

$J0B_1  - job  taken  from  one  of  the  partial  schedules 

$J0B__2  "job  taken  from  the  other  partial  schedule 

$RELATION  - temporal  relationship  between  the  two  jobs 
$RESULT  - returns  from  ELEMENTARY_TEMP_RELATIONS  as  a flag 
to  indicate  the  existance  of  temporal  relations 
between  J0B_^1  and  J0B_2 

$SUB_JOB  - points  to  all  subnodes  of  J0B_1  and  J0B_2 

2 . A . 9 . 8 Modifications  to  Functional  Specifications  anc/or  Standard  Data 
Structures  Assumed 

$SCHEDl  and  $SCHED2  are  equivalent  to  first- level  subnodes  of 
$ SCHEDULE. 
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2.4. 9. 9 COMMEin^ED  CODE 


t 

EXTERNAL.TEMP.RELAT IONS  I PROCEDURE ( SSUBNET  t SSCHED.l * SSCHED.2 » 
STEMP0RAL_VI0LATI0N)  options (EXTERNAL) I 

declare  ssub.job  locals 

DECLARE  I*J*K**J0B_1*SJ0B_2*SRELATI0N  LOCALS 

/*  FORM  A PAIR  OF  JOB  IDENTIFIERS  WITH  OnE  TAKEN  FROM  SSCHEOl  AND  f/ 
/*  one  taken  FROM  SSCHED2  */ 

DO  I = 1 TO  NUMBER (SSCHED.l) I 
LABEL (SJOB'I)  = LABEL (SSCHEO.i ( I ) ) I ^ 

SJ0B_1.J08_INTERVAL  * SSCHEO^l (I ) , JOB.lNTERVALS 
DO  J a 1 TO  number ($SCHED«?) I 
LABEL(SJ0B«2)  a LABEL(5SCHFD'2(J) ) I 
SJOB_2,JOB^INTErVAl  a $SCHf0_2(J) .JOB.INTERVALI 


/*  SELECT  A permutation  OF  ThE  JOB'  PAIR  */ 
/♦  FROM  SJOBSETf  CREATE  ThE  SUBSET  WHOSE  ELEMENTS  ARE  THE  */ 
/*  TEMPORAL-RELATION  OF  THE  FIRST  JOB  IN  THE  PERMUTATION*  WHICH  */ 
/*  ALSO  INVOLVES  THE  SECOND  JOB  OF  THE  PERMUTATION  */ 


PRUNE  SRELATIONI 

IF  Label ($scheo_2(j) ) elemfnt  of  $subnet.#la8EL(sjob.1) , 
TEMPORAL-RELATION.PREDEcESSOP 
then  DOS 

SRELATION(FIRST)  s LaBEL(SSCHE0_2(J) ) I 
LABEL (SPELATION)  a • PREDECESSOR  * S 

ENDS  , , 

else  if  label  ( SSCHED_2  (j)  ) element  oF  $SUBNET.#LA8EUSJ0B_1)  . 
TEMPORAL-RELATION. SUCCESSOR 
THEN  DOS 

SRELATION(FIRST)  a LABEL (*SCHED_2 (J) ) S 
LABEL(SRELATION)  » tSUCCESSORM 
ENDS 

ELSE  DO  K a 1 TO  NUMpER (SSUBNET.#LABEL ( SJOB^l ) • 
TEMPORAL-RELATION. GENERAL) I 

IF  label ($SCHED_2(J) ) a SSUBNET.#LABEL(*J0B_1) . 
TEMPORAL-RELATtON.GFNERAL(K) (4) 

THEN  SRELAT ION  a SSUBNET. #LABEL (SJOB«l ) . 

TEMPORAL.RElATION. general (K) I 
ELSE! 

ENDS 


IS  THE  subset  empty?  */ 

IF  srelation  identical  to  snull  then  go  to  NEKT^PERMS 

/*  SELECT  AN  ELEMENT  OF  THE  SUBSET  »/ 

CALL  ELEMENTARV.TEMPlRELATi0NS(Sj0B_ltSJ0Bl2, SRELATION, SRESUlT) S 
/♦  IS  THE  binary  relationship  SPECIFIED  BY  THIS  ELEMENT  (NODE)  ^^/ 

/*  SATISFIED  BY  THE  START  AnD  END  TIMES  GIVEN  IN  SSCHEDl  AND 
/♦  5SCHED2  for  ThE  JOBS  IN  THE  PAIR?  */ 

IF  SRESULT.SATtSFIED  a iNOt 

/*  CONSTRUCT  A FIRST-LEVEL  SuBNODE  OF  STEMPORAL-VIOLATIONS  */ 

THEN  DOS 

DO  FOR  all  subnodes  OF  SJOBII  USING  SSUB.JOBS 
IF  SSUB_J08  SUBSET  OF  STEmPORaL.VIOLATIOn.#LABEL (SJOB.l ) 

then! 
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ELSE  $TEMPORAL_VIoLATION«#LABEL(SJOB«.1) (NEXT)  * SSUB_JOB| 

(LABEL (SRELATION)  ■ •PREDECESSOR*  I LABEL (SRELATION)  > 

THEN^STEMPORAL^VIoLATION*#LABEL (SJOB^l ) .CONSTRAINT^VIOLATED 
•#LABEL (SRELaTION) (NEXT)  = LABEL ( SJ0B_2) | 

ELSE  $TEMP0RAL^VI0LATI0N*#LABEL (SJOB—1 ) •CONSTRAlNT^VIoi  ATFO 

.seneralTnext)  ■ srelationi 

ENDt 
else  I 

/♦  select  the  other  permutation 

NEXT.PERMI 
PRUNE  srelationi 

IF  LABEL(SSCHED11(I))  element  of  SSUBNET.#LABEL(SJ0B_2) . 
TEMPORAL_RELaT!ON*PREOEoESSOR 
then  OOI  ^ 1 . 

SRELATION(FIRST)  * LaBEL(SSCHED«1 (I) ) I 
LABEL (SRElATION)  « « PREDECESSOR* » 

ELSE  IF  label (SSCHED^l ( I ) ) ELEMENT  oF  SSUBNET.KLABEL (SJ0B^2i . 
TEMPORAI VIOLATION.SuCCESSOR 

^^^SRELATION(FIRST)  ■ LABEL ( SSCHED^l ( I ) ) I 
label (SRELATION)  - »SUCCESSOR»l 

ELSE  DO  K * 1 TO  NUMrER ($SUBNET*#LABEL ( SJ0B_2t • 
TEMPORAL.RELATION, GENERAL)  I 

IF  LABEL(SSCHED«1 (I) ) » $SUBNET,#LABEL ($J0B_2) , 
TEMPORAL«RELATiON. general (K) (4) 

THfN  SRELATION  » $SUBNET.#LABEL (SJOB«2) • 
temporal«reL‘ation,general(K)  I 

elsei 

IF  SRELATION  identical  TO  SNULL  THE^  GO  TO  NEXT  PAIRI  , 

CALL  ELEMENTARY_TEMP.RELATiONS(SjOBS2t$JOB_l« SRELATION* SRESUlT) I 

IF  $result*satisfied  **N0* 

^^00*^F0R  ALL  SUBNODES  oF  5J0B_2  USING  SSUB^JOBI  , _ ^ 

IF  SSUB.JOB  SUBSET  OF  $TEmPORAL„VIOLATIOn*#LABEL ($J0B_2) 

ELSE%TEMPORAL_VIoLATION.#LABEL (SJ0B^2) (NEXT)  * SSUB_J08| 

IF^ (LABEL (SRELATION)  = •PREDECESSOR*  | LABEL (SRELATIONi  ■ 

THEN^STEMPORAl VIOLATION. #LABEL (SJOB.25 .CONSTRAlNT^Vloi  ATFO 

.#LABEL(SREi  ATION)  (NEXT)  = LABEL (SJOB.l ) I 
ELSE  STEMPORAI VIOLATION. #LABEL (SJOB_2) .CONSTRAlNl^VlOl  ATED 

.generalTnext)  » srelationi 

END  I 

/*  HAVE^ALL  PAIRS  OF  JOBS  BEfN  CONSIDERED? 

next.pairi 

END» 

ENDl 

end  EXTERNAL.TEMP-RELATIONSI 
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2.4.10  INTERNAL_TEMP_RELATlON 


2.4.10 


« 


INTERNALJTEMP_RELATIONS 

2.4.10.1  Purpose  and  Scope 

This  module  will  determine  the  temporal  relations  specified 
for  jobs  under  a single  subnode  of  $J0BSET  (i.e.  $SUBNET)  that 
are  violated  within  a single  partial  schedule  that  has  two  or  more  jobs. 

Unlike  EXTERNAL_TEMPJRELATIONS , this  module  will  identify 
all  violations  of  temporal  relations  that  exist  within  a single 
tree  containing  several  schedule  units.  The  module  will  build  an 
output  tree  containing  a first-level  node  for  each  identified  vio- 
lation of  a temporal  relation.  Identifiers  of  the  conflicting  jobs, 
the  identifiers  of  the  violated  temporal  relations  and  the  interval 
of  the  violation  will  be  recorded  for  each  such  node. 

2.4.10.2  Modules  Called 

ELEMENTARY_TEMP_RELAT  ION  S 

2.4.10.3  Module  Input 

This  module  will  be  called  with  three  arguments.  There  are  two 
input  arguments;  $SUBNET  and  $SCHED.  The  structure  of  $SUBNET  is 
identical  to  a single,  first-level  subnode  of  the  structure  output 
■from  the  module  GENERATE_JOBSET . The  structure  of  $SCHED  is  that 
of  the  standard  schedule  unit  (job),  and  is  equivalent  to  a first- 
level  subnode  of  $SCHEDULE . 

The  minimum  data  structures  required  from  the  standard  struc- 
tures $SUBNET  and  $SCHED1  are  shown  in  Fig.  2.4.10.1.  Note  that 
in  the  minimum  structure  the  fifth  and  sixth  subnodes  of  a relation 
in  the  TEMPORAI^ RELATION  substructure  are  not  mandatory  in  every 
case . 
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Note:  Minimum  (i.e.,  relevant)  portion  of  the  required  input  standard  data 

structures  is  shown.  In  all  trees,  any  additional  structure  will  be 
preserved.  

$SUBNET 


$SCHED 


Fig.  2.4.10-1 

Minimum  Required  Input  Struatures  from  Standard  Data  Struatures  for  Module: 

CHECK  INTERNAL  TEMP  RELATIONS 


ORIGINAL  PAGE  IS 
OF  POOR  QUAliOT 
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2.4.10.4  Module  Output 


This  module  will  build  and  return  an  output  tree  with  the 
structure  shown  below: 


OUTPUT  DATA  STRUCTURE 


JTEMPORALJ/IOLATION 


Each  node  of  $TEMP0RAL_VI0LATI0N  will  correspond  to  a violation  of 
a temporal  relation  in  $SUBNET  (input)  that  appears  internally  xn 
$SCHED  (input) . 
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2.4.10.5  Functional  Block  Diagram 
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2.4.10.6  Detailed  Design 


The  functional  block  diagram  provides  the  flow  chart  for  this  module. 
The  module  selects  each  job  in  turn  from  an  input  schedule  unit.  Each 
temporal  relationship  of  the  job,  whether  predecessor,  successor,  or 
general,  is  utilized  in  a call  to 'the  module  ELEMENTARYJTEMP_RELATION 
to  determine  the  satisfaction  of  the  relationship.  If  the  relationship  is 
not  satisfied,  a node  is  built  to  identify  the  teaiporal  violation.  The 
next  temporal  relation,  or  the  next  job  is  Che  selected  and  the  procedure 
repeated . 

2.4.10.7  Internal  Variable  and  Tree  Names 

$JOB_l  - job  taken  from  the  partial  schedule 
$JOB__2  - job  related  temporally  to  $J0B_1 

$RELATI0N  - temporal  relationship  between  the  two  jobs 

2.4.10.8  Modifications  to  Functional  Specifications  and/or  Standard  Data 
Structures  Assumed 

Only  a single,  aubnode  of  $J0BSET  is  examined  with  each  call  to  this 
module,  so  this  subnode  is  identified  as  $SUBNET  through  the  parameter  list. 

$SCHED  is  equivalent  to  a first  level  subnode  of  $ SCHEDULE . 
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2.4.10.9  Commented  Code 


internal„temp»relationsi  procedure <ssubnet»$sched* 

STEMPORAL..VlOLATlONi  OPTIONS (EXTERNAL) » 

/*  create  a SET  OF  ALL  JOB  IDENTIFIERS  IN  SSCHED  WHICH  HAVE  NON-  f/ 
/*  NULL  TEMP0RAL_RELATI0N  NODES 
DO  I a 1 TO  number (SSCHED) I 
label (SJ081)  * LABEL(*SCHED(I j ) I ^ 

SiJOBUJOB.INTERVAL  * SSCHED  ( I ) #J0B_INTERVAH 
/•  SELECT  A JOB  FROM  THE  SET 

/♦  SELECT  NEXT  TEMPORAL^RELAtION  FOR  THIS  JOB  */ 

DO  J a 1 TO  number ($SUBnET.#LABFL (SJOBI) .temporal.relation* 
PREDECESSOR) I 
PRUNE  SRELATIONI 

LA8EL(SJ0B?)  = SSUBNET.wLABEL (SJOBI) .TEMPORAL^RELATION. 
predecessor (J) I 

SJ0B2.J0B_INTERVAL  » SScHED.WLABEL (SJ0B2) .JOB.INTERVALI 
SRELATIOnTfIRST)  a label  (SJOB2M 
LABEL (SRELATION)  a » PREDECESSOR ♦ I 

CALL  elementary  TEMP^REi  ATIOnS (SjOBl tSJOB2*SRELATlON,$RESULT) I 
IF  SRESULT. SATISFIED  = tNO* 

THEN  DO« 

STEMPORAL* VIOLATION(NEXT)  aSJOBlI 

*TEMPORAL_VIOLATION(LAST) .cONSTR a I NT..V I OLATED. PREDECESSOR 
(NEXT)  a label (SJOB?) I 
END? 

ENOI 

DO  J a 1 TO  number (SSUBNET.#LABEL (SJOBI) .temporal.relation. 
SUCCESSOR) I 
PRUNE  SRELATiON? 

LABEL (SJOB2)  » $SUBNET.#LABEL (*JOBl ) •TEMPORAL.RELATION, 

SUCCESSOR( J) » 

$J0R2.J0B_INTERVAL  = 5ScHED,WLABEL($JOB2) .JOB^INTERVALI 
srelationTfirsT)  a Label (SJOB2) ? 

LABEL (SRELATtON)  a ♦SUCCESSOR*! 

CALL  ELEMENTaRYITEMPIrEl AT IONS ($j0Bl#SJ0B2t SRELATION t SRESULT) ! 

IF  SRESULT. Satisfied  a »no» 

THEN  do? 

STEMPORAL  VIOLATIoN(NEXT)  a SJOBl! 

STEMPOPAlIvIOLaTION(LaST) .constraint.violated. successor 
(nexT)^  labeL(Sjob?)  ; 
end? 

END! 
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DO  J » 1 TO  NUMrER(*SUBNET,#LABEL($JOB1) ,temporal«relation. 
GENERAL) I 
PRUNE  SRELATIONi 

Label (SJ0B2)  « *subnet,«label(sjobi) •temporal^relation. 
general (J) (A) I 

»J0B2.J0B_INTERVAL  « SScHED,#LABEL($J0B2) ,job„interval» 
SRELATION  « SSUBNET.#LArEL(SJOB1) . temporal-relation, general u) I 
CALL  ELEMENTaRY1tEMP_REL’aTI0NS(SJ0B1*SJ0B2iSREL.aTI0N*SRESULT)  I 
IE  SRESULT. satisfied  * iNO* 

THEN  DO» 

$TEMPORAL_VlOLATIf>N(NEXT)  « $JOBH 
*TEMPORAL_VIOLATIoN(LAST) ,constraint«violated. general 

(NEXT)  « SRELATIONI 

end  I 

/*  have  ALL  TEMPORALIrELATIOm  FOR  THIS  JOB  BEEN  CONSIDERED? 

END! 

/♦  HAVE  ALL  JOBS  IN  SSCHED  BfEN  CONSIDERED? 

ENDI 


END  INTERNAL_TEmP.RELATIONSI 
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4.11  ELEMENTARY  TEMP  RELATIONS 


2.4.11  ELEMENTARY_TEMP_REIATIONS 

2.4.11.1  Purpose  and  Sco^e 

This  module  is  elementary  in  the  sense  that  it  determines 
satisfaction  or  nonsatisfaction  of  a single  input  relationship 
involving  the  start  or  end  times  of  two  jobs  for  which  specific 
start  and  end  times  have  been  assigned.  The  principal  use  of  thxs 
module  is  to  service  higher  level  logic  that  is  checking  multiple 
temporal  relations  between  or  within  sets  of  jobs. 

2.4.11.2  Modules  Called 
None 

2.4.11.3  Module  Input 

There  are  three  input  arguments  to  this  module.  These  are 
$J0B1,  $J0B2,  and  $RELATI0N.  The  structure  of  $J0B1  and  $J0B2  xs 

shown  below: 


$J0B 
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The  structure  of  $RELATI0M  is  the  structure  of  one  of  the  sub- 
nodes of  TEMPORAL_RELATION'  shown  in  the  section  on  standard  data 
structures.  This  module  assumes  that  $J0B1  is  the  same  job  for 
which  the  structure  TEMPORAL_RELATION  is  written  and  that  $J0B2 
is  the  other  job  that  is  referred  to  in  the  fourth  subnode  of  the 
special  structure  of  $RELATI0N.  Note  that  in  illustrating  the 
minimum  required  data  structure  for  this  information  that  the  fifth 
and  sixth  subnodes  for  the  structure  $RELATI0N  are  not  mandatory  to 
specify  temporal  relationships  in  every  case. 
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Note:  The  minimum  (i.e.,  relevant)  portion  of  the  required  input  standard 

data  structures  is  shown.  In  all  trees*  any  additional  structure  will 
be  preserved. 


$RELATI0N 


$RELATI0N 

OR  O PREDECESSOR 


9* 

(NAME) 

$RELATION 

OR  Q SUCCESSOR: 

V* 

(NAME) 


M’ini’ttMti  ReciU'Cved  Input  StTuctupes  from  Standard  Data  Struotures  for  Module: 
EIEMENTARY  TEMP  RELATIONS 
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2. A.  11. A Module  Output 


This  module  returns  a tree  $RESULT  with  two  first  level  subnodes 
as  shown  below: 


$RESULT 


The  value  returned  for  the  LEFT_MINUS_RIGHT  node  is  simply  the 
algebraic  result  of  subtracting  the  quantity  on  the  right  of  the 
binary  oper.ator  (^,  <,  >)  of  the  input  TEMPORAL_RELATION 


from  the  quantity  on  the  left.  If  the  module  is  called  with  a 
PREDECESSOR  or  SUCCESSOR,  this  module  assumes  the  following  equiv- 
alent relations  to  compute  the  LEFT_MINUS_RIGHT  value: 

GENERAL  RELATION 


START 


END 


OF  j(J0B_ID)j 


(CONSTANT) I 


LEFT  SIDE 


PREDECESSOR 


RIGHT  SIDE 


SUCCESSOR 


END  OF  J0B2  - START  OF^JOBJ.  START  Or  J0B^2  > END  OF  JOB  1 
LEFT  SIDE  RIGHT  SIDE  LEFTJIDE  RIGHTJIOE 
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2.4.11.5  Functional  Block  Diagram 

ENTER ^ 


Yes 


LEFT  SIDE  ' END  OF 
J0B2 

RIGHT  SIDE  » START  OF 
JOB! 

LEFT  SIDE  - START  OF 
JOB2 

— — , 

RIGHT  SIDE  » END  OF 
JOBl 
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2. A. 11. 6 Detailed  Design 

The  functional  block  .diagram  provides  the  flow  chart  for  this  module. 
This  module  takes  the  two  Input  jobs  and  constructs  values  called  left 
side  and  right  side  dependent  upon  the  relationship  between  the  two  Jobs. 
For  the  general  temporal  relationship;  left  side  is  the  value  of  the 
first  subnode,  right  side  is  the  evaluation  of  subnodes  three  through  six. 
If  J0B_^2  is  a predecessor  of  JOB^l,left  side  is  the  end  of  J0B_2,  right 
side  is  the  end  of  JOBl.  If  J0B_2  is  a successor  of  J0B_1,  left  side 
is  the  start  of  J0B_2,  right  side  is  the  end  of  J0B_1.  The  difference  in 
value  between  left  side  and  right  side  id  determined  and  satisfaction  of 
the  temporal  relation  is  checked.  If  the  difference  is  positive  (greater 
than  zero)  and  the  temporal  relation  is  "SUCCESSOR”  or  the  value  of  the 
second  node  of  the  general  relation  is  or  the  relation  is  satlS” 

fled.  If  the  difference  between  left  side  and  right  side  is  negative  and 
the  temporal  relation  is  "PREDECESSOR"  or  the  second  node  is  or 
the  relation  is  satisfied.  If  the  difference  is  zero,  the  relation  is 
satisfied  by  temporal  relations  "PREDECESSOR”  and  "SUCCESSOR”  and  by  second 
nodes  values  and 
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2.4.11.7  Internal  Variable  and  Tree  Names 


LEFT_SIDE  - reference  to  the  value  In  Che  general  tenporal  relation 
to  the  left  of  the  logical  relation,  l.e.  the  first 
subnode . 

RIGHT_S1DE  - reference  to  the  evaluation  of  the  general  temporal 
relation  to  the  right  of  the  logical  relation,  l.e., 
nodes  three  through  six. 

LEFT  RIGHT  - the  difference  between  LEFT  SIDE  and  RIGHT  SIDE 


2.4.11.8  Modifications  to  Functional  Specifications  and/or  Standard  Data 
Structures  Assumed 


None 
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2.4.11,9  Commented  Code 


EI:EMENTARY_TEMP_RELATI0NS*  procedure ($J0B1 f$JOB2*$RELATlON* 

SRESULT)  OPTIONS (EXTERNAL) I 
DECLARE  LEFT_SIOE»RIGHT_SIDE«LEFT1rIGHT  LOCALI 
/«  IS  srelation  a predecessor? 

IF  LABEL (SRELATION)  a f PREDECESSOR ♦ 

THEN  DOJ 

LEFT_SIDE  X fJ0B2.J0B_lNTERVAL.ENDl 

RIGHT_SIDE  » sjobi.job_tnterval.starti 
end? 

IS  SRELATION  A SUCCESSOR? 

ELSE  IF  LABEL(SRELATION)  x ’SUCCESSOR* 

Then  do? 

LEFT_SIDE  a SJ0B2. JOr  tnTFRVaL«START? 

RIGHT_SIDE  a fJ081.jR8_lNTERVAL.EN0l 
END? 

ELSE  DO? 

LEFT„SinE  X f jOBleJOR_lNTFRVAL.«<SRELATlON(l) 

IF  SRELATION(S)  a *-« 

THEN  RIGHtIsIDE  a f JOB?. JOB-INTERVAL.# ($RELATI0N(3)  j - 
$rELATI0N(6) ? 

else  RIGHtIsIDE  a $J0B2. JOB-INTERVAL. #(SRELATI0N(3)  ) + 
SRElATI0N(6) % 

END? 

/♦  COMPUTE  LFFTlSiDE  MINUS  RIGHT-SIDE 
LEFT_RIGHT  s LEFT_SI0E  - Rl6HT_SlDFl 

sresult*left1minus_right  a leftIright? 

IF  LEFT_RIGHT  > 0 

THEN  IF  (LABEL (^RELATION)  s ’PREDECESSOR*  | SRELATION(?)  x T 

SRELATlONt?)  a »<xe  j $pELATI0N(2)  x f*i) 

Then  do? 

SRESULT. satisfied  x ,no’I 
return? 

END! 

else  do? 

SRESULT. Satisfied  « *yes»i 
return? 

END? 

ELSE  IF  LEFT_rIgHT  < 0 

Then  if  (label($relatiom}  x »successor’  i srelation(2)  = ,>f  i 

SRELATI0N(2)  a »>xt  I $RELATI0N(2)  X »X’> 

THEN  DQ§ 

SRESULToSaTISFIED  X «NO»l 
RETURN? 

END? 

ELSE  001 

SRESULT. Satisfied  x »yfsm 

RETURN? 

end? 
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ELSE  IF  (SRELATI0N(2)  ■ »<•  I SRELAtI0N(2)  a *>i) 
THEN  DOI 

$RESULT«SaTISFIEO  ■ »NOM 
RETURN! 

END! 

ELSE  DO! 

SRESULT. Satisfied  = 'yesm 

RETURN! 

END!  ^ 

ENDI  /*  p L pMf- M r?pY_T  FNP_WFL  */ 
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2.4.12  NEXTSET 


2.4.12  NEXTSET 

2.4.12.1  Purpose  and  Scope 

This  module  accepts  an  abstract  description  of  item  specxfic 
resource  requirements  associated  with  -i  specific  job  and,  by  re- 
ferring to  information  about  the  assignments  already  scheduled 
for  the  resources,  determines  the  earliest  possible  time  (within 
a designated  interval)  at  which  the  resource  requirements  can  be 
fulfilled.  It  generates  all  information  required  to  actually  place 
the  job  on  the  schedule  but  does  not  cause  resource  assignments 
to  be  written.  The  module  also  determines  the  time  intervals 
during  which  the  resource  requirements  are  met  using  the  same 
permutation  of  resources  and  time  intervals  for  which  any  permuta- 
tion of  available  resources  meets  the  requirements. 

2.4.12.2  Modules  Called 

DURATION 

INTERVAL_UNION 

INTERVALJNTERSECT 

FINDJMIN 

2.4.12.3  Module  Input 

$ABSTRACT  is  a tree  structure  that  describes  the  job  in  terms 
of  its  general  characteristics,  resource  requirements,  and,  if 
applicable,  in  terms  of  any  user-designated  specific  resource 
allocations.  Its  structure  is  shown  on  the  following  page. 
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ORTfinjA 


PROSlfM  NMWC 


r-SPLITT/WlP'  1 "HOHSPLITT«m 


5ABSTRACT 


KSCRIPTO* 


) QUANTITY  ( ) (PARAKUR)  ( ) • • • 


Except  for  the  job,  process,  and  resource  intervals,  the  in- 
formation is  exactly  as  used  elsewhere  for  abstract  process  and 
job  description.  Specifically,  the  information  is  in  the  form 
generated  by  the  module  GENERATE_JOBSET . 

Since  the  absolute  start  and  end  times  of  the  jobs,  processes, 
and  resource  allocations  are  an  output  of  this  (and  other)  modules, 
rather  than  an  input,  the  intervals  in  this  structure  are  rela- 
tive. The  resource  interval  represents  the  start  and  end  times 
(relative  to  the  start  of  the  process)  of  a single  resource  al- 
location. These  relative  times  may  be  positive,  zero,  or  (very 
rarely)  negative. 

The  absolute  start  and  end  times  of  interest  are  specified  in 
the  argument  list  as  subnodes  of  $REQUESTED__INTERVAL  to  limit  the 
scope  of  assignments  considered,  and  $RESOURCE  is  referenced  to 
allow  access  to  the  resource  assignments. 

If  for  a given  resource  unit,  the  resource  unit  name  is 
specified  (i.e.,  LABEL ($ABSTRACT. RESOURCE (J) (K) ) is  not 
null,  then  it  is  assumed  that  the  named  resource  unit  is  to  be 
used.  Regardless  of  the  specification  or  nonspecification  of  the 
resource  unit,  the  requirements  (descriptors,  quantity,  etc.) 
still  apply  and  must  be  satisfied,  if  possible,  by  NEXTSET. 


■ 2.4.12-3 
Rev  C 


Note*  The  minimum  (i.e.,  relevant)  portion  of  the  required  input  standard 
’ data  structures  is  shown.  In  all  trees,  any  additional  structure 

will  be  preserved. - 


$ABSTRACT 


(NAME) 


Minimum  Required  Input  Structures  from  Standard  Data  Structures  for  Module: 

NEXTSET 
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2.4.12.4  Module  Output 


The  output  of  NEXTSET  consists  of  two  output  trees,  $C0NCRETE 
and  $AVA1LABLE_WIND0WS . $CONGERETE , as  shown  on  the  following  page, 
describes  a specific  execution  of  a job,  with  all  times  and  resource 
allocations  fully  specified  in  absolute  terms  at  the  earliest  avail- 
able opportunity  within  the  specified  window.  $AVAILABLE_WINDOWS , 
also  shown  below,  defines  all  of  the  available  time  intervals, 
within  the  specified  window,  for  the  set  of  resources  correspond- 
ing to  the  set  representing  the  earliest  available  time.  It  also 
defines  the  available  time  intervals  if  any  permutation  of  ac- 
ceptable resources  is  considered. 


$AVAILABLE_WINDOWS 
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OUTPUT  DATA  STRUCTURE 


$CONCRETE 


ii 

1 
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2.4.12.5  Fnnrtional  Block  Diagram 


Consider 
next  required 
resource 
type. 


Consider  next  permutation 
of  available  resource  ^ 

units  over  set  of  resource  Xp 
requirements.  c 


Consider  next  element  of 
current  permutation.  This 
element  constitutes  the 
association  of  a specific 
resource  unit  with  a 
requirement.  _ 


Calculate  intervals  of 
job  start  times  for 
which  association  sat- 
isfies all  constraints. 


Find  intersection 
of  resulting 
intervals . 


Find  intersection 
of  resulting 
intervals 


Construct  concrete  schedule 
unit  based  on  start  time 
of  first  subinterval  of  this 
intersection. 


'Find  union 
of  resulting 
i;},tervals. 

Cell  it  C. 
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2.4.12.6  Typical  Applications 


This  module  can  be  applied  to  both  time  progressive  and  time 
transcendent  scheduling  procedures.  The  module  identifies  the 
earliest  time  within  a given  interval  at  which  the  resource  re- 
quirements of  a single  job  are  fulfilled  by  some  permutation  of 
item-specific  resource  elements.  The  time  intervals  within  the 
given  interval  for  which  the  resource  requirements  are  met  with 
the  selected  permutation  of  resources  are  identified  permitting 
scheduling  based  on  criteria  other  than  earliest  start  time. 

Time  intervals  for  which  any  permutation  of  resources  meet  the 
requirements  allow  the  same  flexibility  of  scheduling  criteria; 
however,  permutations  of  resources  other  than  the  earliest  are 
not  identified. 
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2.4.12.7  DETAILED  DESIGN 


The  logical  path  for  the  module  NEXTSET  Illustrated  in  the  Functional 
Ulock  Diagram  is  developed  in  greater  detail  in  the  flowchart  presented 
in  the  sketch  belov7.  The  module  starts  by  determining  that 
the  standard  data  structure,  $RESOURCE,  contains  at  least  as  many  resource 
elements  of  each  type  as  is  required  by  the  input  structure,  $ABSTRACT. 
Given  that  enough  resources  are  named , the  module  develops  a usage  profile 
for  each  resource  element  of  all  the  resource  types  requested  by  $ABSTRACT 
over  the  period  of  interest.  From  the  usage  profile  the  availability  pro- 
file is  readily  developed  for  the  same  time  period.' 

Since  permutations  of  available  resource  units  over  the  set  of 
requirements  will  be  formed,  the  required  resource  units  specified  by 
name  must  be  included  in  each  permutation.  To  accomplish  this,  a tree  is 
formed  containing  only  the  labels  of  the  names  of  available  resource  units. 
From  this  tree  are  pruned  the  names  of  the  specified  resource  units  and  the 
remaining  tree  structure  is  utilized  for  the  formation  of  the  permutations. 
The  intervals  of  the  start  times  for  the  specified  resource  units  is  deter- 
mined and  the  intersection  of  these  intervals  is  maintained  for  combination 
with  acceptable  permutations. 

For  each  resource  type  all  permutations  of  available,  unspecified 
resources  are  taken  over  the  set  of  required  resources.  Then  each  element 
of  each  permutation  is  checked  for  ,a  match  of  descriptors  between  required 
and  available.  If  an  element  of  the  permutation  does  not  provide  this 
match,  no  further  elements  are  checked  and  the  next  permutation  is  tested. 
When  all  elements  of  a permutation  match  descriptors,  the  interval  of  start 
times  for  each  element  is  calculated . The  intersection  of  these  intervals 
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forms  an  interval  of  start  times  for  one  permutation  of  one  resource  type. 
When  all  permutations  for  a given  resource  type  have  been  formed,  and  at 
least  one  interval  of  start  times  has  been  identified,  the  union  of  inter- 
vals of  the  various  permutations  provides  the  interval  of  feasible  start  ' 
times  for  the  current  resource  type.  If  no  feasible' intervals  are  deter- 
mined, an  error  message  is  printed,  and  control  is  returned  to  the  calling 
program. 

After  the  intervals  of  feasible  start  times  for  all  resource  types 
have  been  determined , the  Intersection  of  these  intervals  is  the  desired 
Interval  of  times  at  which  the  process  may  be  started  using  some  set  of 
resources.  The  resource  set  yielding  the  earliest  start  time  is  then 
identified  and  the  interval  over  which  the  process  may  be  started  using 
this  resource  set  is  determined.  The  output  data  structures  are  then 
constructed  and  control  returned  to  the  calling  program. 
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NEXTSET  FLOWCHART 


Select  next  required 
resource  from  $ABSTRACT 


available  resources  ^ 
.^number  of  required^ 
^’"^resources 


Set  error  flag 


Return 


Have 

all  required  resource 
types  been  checked 


Consider  each  assignment 
of  each  resource  name 
of  each  required  resource 
type  found  in  $RE SOURCE 


Is 

the  assignment 
within  the  interval 
''''''\oflnterest^^^,^ 


Insert  assignment  into 
$TEMP_STATE . IN-USE 


Create  $TEMP_ST ATE. AVAILABLE 
by  subtracting  IN_USE  portion 
from  interval  of  interest 
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NEXTSET  FLOWCHART  (cont) 


D 


NEXTSET  FLOWCHART  (cont) 


Form  the  next  permutation 
of  available  resources  taken 
the  number  required  at  a time 


'^the  descriptors  of^ 
required  and  available 
"'^■''-^es^rces  matcJiZ'''^ 


Have 

'■'■'all  elements  of  ^ 
this  permutation  been 
checked 


Calculate  intervals  of 
start-times 


Find  intersection  of 
start-time  intervals 


Include  specified  resources  ir 
interval  for  this  permutation 


^.o^'all  permutations  of^"\. 
vallable  resources  of  this 
^''^ype  been  considered''"^ 


Has 

"at  least  one  interval 
identified^^ 


Set  error  flag 


Return 
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NEXTSET  flowchart  (concl) 
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2.4.12.8  INTERVAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 


AVAIUBLE_DURATION  - 

BEGINJTIME 

ENDjriME 

INDEX 

WINDOW 

REQUIRED_DURATION 

$ASSIGN_INT 

$AVAIL_INT 

( 

$AVAIL_PROFILE 

$INTER_ASSIGN 

$ INTERSECT 


the  length  of  time  a given  resource  element  is 
available 

earliest  start  time  meeting  all  resource  constraints 
earliest  time  following  BEGIN_TIME  for  which  the 
resources  to  be  used  are  no  longer  available 
tree  subnode  indicator  of  one  of  the  required 
unspecified  ref'Ource  names 

single  subnode  of  $WINDOW_SET,  an  interval  denoting 
one  interval  of  start  times  for  a resource  element 
required  more  than  once  during  a process 
the  length  of  time  a given  resource  element  is 
required 

a standard  interval  sturucture  denoting  the  time 
periods  a given  resource  element  is  in  use 
A standard  interval  structure  denoting  the  time 
periods  a given  resource  element  is  available 
a standard  interval  structure  denoting  feasible 
start  times  for  a single  resource  element 
a tree  structure  containing  descriptors  and  intervals 
of  the  resource  set  having  earliest  start  time,  used 
to  construct  $CONCRETE 

a standard  Interval  structure  used  to  determine 
feasibility  of  a resource  element  required  more 
than  once  during  a process 
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$INTERSECTION  FINAL  - 


$ INTERSECT ION  INITIAL  - 


$INTERSECTION  SPECIFIED 


$NAME 


$REQ_INT 


$REQUIRED  INDICES 


$SAME  SET 


$SPECIFIED  PROFILE  - 


$TEMP  ASSIGN 


$TEMP_INT 


■$TEMP  RESOURCE 


the  (multiple)  interval  of  feasible  start  times 
with  any  resource  set 

the  interval  of  feasible  start  times  for  one 
resource  set 

- the  interval  of  feasible  start  times  for  the 
specified  resource  names  only 
a single  node  tree  whose  value  is  the  label  of 
one  resource  element 

a standard  interval  structure  denoting  the  time 
periods  a given  resource  element  is  required 
a tree  whose  subnode  values  are  the  position 
indicators  (in  $ABSTRACT)  of  the  required, 
unspecified  resources 

the  (multiple)  interval  of  all  feasible  start  times 
using  the  resource  set  that  provides  the  earliest 
possible  start  time 

a standard  Interval  denoting  feasible  start  times 
of  all  the  specified  resources 

a tree  structure  providing  the  Intervals  of  start 
times  and  resource  names  for  each  feasible  permu- 
tation group. 

a standard  interval  structure  used  in  determining 
multiple  interval  requirements 
tree  structure  containing  usage  and  availability 
descriptions  for  all ‘required  resources,  built  from 
$TEMP  STATE 
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$TEMP  STATE 


tree  providing  usage  and  availability  descriptions 


$TYPE 


$UNSPECIFIED 


$WINDOW  SET 


of  a single  required  resource 
a single  node  tree  whose  value  is  the  label  of 
a resource  type 

RESOURCE  - a tree  whose  values  are  the  names 

of  the  item  specific  resources  of  a single  type; 
and  which  are  not  specifically  required 
a standard  interval  set  defining  feasible  start 
times  for  a resource  element  which  is  required 
more  than  once  during  a process 
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2.4.12.9  Commented  Code 


NIXTSET*  procedure ($ABSTRACTt«REQUFSTEO«INTeRVAL»SRESOURCE,$CONCREfE* 
SAVAILABLE^WINDOWS)  options (EXTERNAL) » 

DECLA  E '^SPEClFlEDlRESOURCEfNS  LOCAL? 

declare  sint_un!On#num#$save^intersection  local? 
declare  stemp_assign>  sinter.assign,  stemp_resource»  stempIstatf, 

SUNIONf  $lNTERSECTlON_lNTTIALf  SlNTERSECTlON^SPEClFIEDt 
SINTERSECTIONIFINAL  local! 

DECLARE  I*J*K*L*KKfLL»START*  NUMBERi^PERMUTATIONiAVAlLABLE.DURAfTON,'' 
SpECIFlED_OURATlONfREQUTRED^t)URATlONf INDEX t delta t WINDOW  LOCAL ? 
DECLARE  VAL.MIN#BE6IN1tIME*ENd»TIMF*FInISH  LOCAL? 

DECLARE  STYPEt$UNSpEClFIEb_REROURCFf*REQUlREDllNDlCESfSNAME  LOCAL! 
declare  SSPEClFlEDlPROFILE**lMTERSECTION.SPECIFlEDt$PERMUTATlON  LOCAL  I 
DECLARE  SAVAIL^PROfILE#SREQ_IwT#$a<;SIGN-INT*SAVAIL«.INT#$TEMP_INT* 

SWINDOW_SET*$INOICES#SInTER^ECTION.INITIAL*SINTERSEcTION_FINAL» 
SSAME^SET#$1nTERSECT*$FoUND£!UNION  local? 

SET^INITIAL.VALUESI 

prune  SAVAILABLE^WInDOWS? 

PRUNE  SCONCRETE? 
prune  sunion? 

START  « SREQUESTeD^INTERVAL. START! 

FINISH  a SREQUESTEOliNTERVAi  ,END! 

IF  FINISH  < START 
then  DO! 

WRITE  'REQUESTED  INTERVAL  OF  SHORTER  DURATION  THEN  JOB  INTFRVaL 

*•  scheduling  Impossible*! 

RETURN! 

end? 

SINTERSE(1TION_INITIaL*START  a START! 

SINTErSECTION^INITIaL.END  « FINISH! 

SINTERSECTIONIFINAL, START  START? 

SINTERSECTIONIFINAL, FNO  a FtNISH! 

SINTERSECTI0N_SPECIFIED*START  a START? 

SINTERSECTION^SPECIFIED.END  a FINISH! 

PRUNE  STEMP^ASSlGN? 

PRUNE  STEMP-PESOURCE? 

/•  SELECT  NEXT  REQUIRED  RESOURCE  FROM  SA8STRACT  »/ 

DO  I a 1 TO  number (SABSTRACT.RESOURCE  )? 

/*  IS  NUMBER  OF  available  RESOURCES  >a  NUMBER  OF  REQUIRED  RESOURCES?  •/ 
IF  number (sabstract, resource  (D)  > NUMBER(SRES0URCE.# 
label (SABSTRACT.RESOURCE  (I))) 

THEN  DO! 

WRITE  'NOTIeNOUGH^RESoURCESIaVaILABLE* ! 

RETURN! 

/♦  HAVE  ALL  required  RESOURCE  TYPES  BEEN  CHECKED?  i/ 

end? 

END! 

/*  CONSIDER  EACH  ASSIGNMENT  OE  EACH  RESOURCE  NAME  OF  BACH  REQUIRED  */ 
/♦  RESOURCE  type  FOUND  IN  SRfSOURCE  i/ 

DO  I a 1 TO  number (SABSTRACT.RESOURCE) ! 

LABEL (STYPE)  * LABEL (SABSTRACT.RESOURCE  (I))? 

LABEL (STEMP.RESOURCE ( T) ) a LABEL ( STYPE ) ! 
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/♦  INSERT 
IF 


IF 


/♦ 

/♦ 


create 


= STARTI 

, Initial  i 
JNITIALI 


from 

♦ / 


DO  J » 1 To  NUMBER ($RFSoURCE.#LABEL (STYPE) ) I 
LABEKSNAME)  » LABeUsRESOURCE.«^LABEL($TYPE)  (J>  ) I 
LABEL(STEMP„RESOURCE<I) (J) ) = LABEL (SNAME) I 

DO  K B 1 TO  NUMBER(SRES0URCE.<*LABEL (STYPE) (J) .assignment) I 
/*  IS  THE  assignment  WITHIN  THE  INTERVAL  OF  INTEREST?  #/ 

IF  (START  >a  SRESOuRCE,«LABEL($TYPE) (J) .ASSlGNMFNT(Ki • 
INTERVAL. END  I FINISH  <*  $RESOURCE.#LABEL  (STYPE)  (^J)  . 
ASSIQNMENT(K) .Interval. START)  THEN  60  TO  enhIloop^ki 
else  $TEMP_STATf.!NE:USE(NEXT)  = SRES0URCE.#LA8EL (STYpE) 

(vJ)  .assignment  (Kj  I 

end_loopj<i  end I 

assignment  into  $TfMP.STATE.IN„USE  */ 

5TEMP1STATE.IN.USE{I) .interval. START  < START 

STEMPIsTATE.InuUSE(I)  identical  to  snull 
THEN  STeMP_STATE.IkuUSE(1) .INTERVAL. START  « STARTI 
STEMP_STATE.IN.USE (LAST) .Interval. END  > FINISH 
fi.  STEMP_STATE.Im_U5E(LAST)  -»  identical  to  snull 
THEN  STeMP_STATE.In_USE(LAST) .INTERVAL.END  = FiNISHi 

stempIstate. available  by  subtracting  in.use  portion 
interval  of  interest 

STEMPISTATE.AVAILABLE(I) .INTERVAL. START 
STEMP.STATe.AVAILABLE(I) .descriptor  (1) 

STEMpIsTATE.IN.USE(I) ^DESCRIPTOR  (1 ) 
do  K a 1 to  NUM8ER($TEMP.STATE.IN.USE) I 
$TEMPlSTATE.AVAlLABLE(Ki  .interval. END  *= 

$TEMP.STATE.IN.USE(K) .INTERVAL.STARTI 
$TEMp1staTE.AVAILABLE(K+1) .interval. START  a 
( STEMP.STATE.IN.USE(K) .interval. ENDI 

$TEMP_STATE.AVAILA8LE(K*1 ) .descriptor  (1). initial  * 
STEmP.STATE.IN.USE(K) .DESCRIPTOR  (1) .FINAL! 

END! 

IF  STEMp1stATE.IN.USE (LAST) .interval. END  = FINISH 

$TEMP1.STATE.In.USE(LAST)  IDENTICAL  TO  SNULL 
THEN  PRUNE  STEMP.SfATE . A VA IlABLE ( LAST > I 

ELSE  STEMP_STATE.AvAILARLE(LAST) .INTERVAL. END  a FINISH! 

IF  STEMp1STATE.IN.USE(1) .interval. START  = START 

& STEMPIsTaTE.Im.USE(I)  IDENTICAL  TO  SNULL 
THEN  PRUNE  STEMP.STATE. AVAILABLE ( rfl 
/*  FORM  NEXT  SUBNpDE  OF  STEMp  RESOURCE  BY  GRAFTING  ON  STEMP_STaTF  « 
graft  STEMP_STaTE  at  STFMPIrESOURCE.^LABEUSTYPE) .#LABEL(SNAME) I 
enoi 

/*  HAS  EACH  assignment  (NAME.  TYPE)  BEEN  CONSIDERED?  »/ 

END! 

CONSIDER.NEXT.RESOURCE1TYPES 

DO  I » 1 TO  NUMBER(SABSTRACT. RESOURCE) I 
PRUNE  SREQUIRED.INDICESI 
prune  $SPECIFIEO_PROFILEI 
prune  SUNSPECIFIED.RESOURCE* 

NUMBER.PERMUTATION  a 01 

/•  SEPARATE  SPECIFIED  FROM  UNSPECIFIED  RESOURCES  #/ 

SEPARATE.SPECIFIc|RESOURcES! 
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> V 


/#  form  sunspecified^resource  with  labels  of  available  resource  Names#/ 

DO  J « 1 To  NUMBER($TfMP^RFSOURCE(I) ) I 

LABEL  <SUNSPECIFIED.RER0URCE (NEXT)  ) « 

LABEL(STEMP»RESnURCE(I)  (J5  5 5 


/♦ 

/♦ 

/• 

/• 


/♦ 


CONSIDER  each  REQUIRED  RESOURCE  TYPE  AND  NAME 

DO  J * 1 TO  NUMBER(SArSTRACTbRESOURCE  (I))J 
IS  THIS  RESOURCE  ELEMENT  SPECIFIED. TO  BE  USED? 

IF  label (SaBSTRACT, RESOURCE  (I)<U))  ® 

PLACE  THE^INDEX  OF  THIS  RfOUIREO  RESOURCE  ELEMENT  IN 
SREQUIRED^INDlCES 

$REQU1RED„INDICfS(NEXT)  s UI 
GO  TO  END-SEPARaTE„SPECIFIED? 

CALCULATE  INTERVALS  OF  STaRT  TIMES  OF  SPECIFIED  RESOURCES 
ELSE  DOI 

PRUNE  SSPEClFlEn^PROFILE?  i- 

IF  sabstract, resource  (I) (J) (1) ^interval  identical  to 

$NULI 


*/ 


#/ 


« 


*/ 


Then  call  dupation($abstract«job_interval* 

specified^ DURATION) I . 

Else  SPECIFIrOlDURATlON  - $A0STRACT *RESOURCE ( I ) ^ 

( J j (LAST) ■ INTERVALe^ND  « SABSTRACT »RES0URCE ( I ) ( J) 
(1) .INTERVAL«START|  ^ 

DO  K = 1 TO  NUMBER($TEMPi_RESOURCE (I) (U) .AVAILABLE) I 

Call  ouration(stemp_r^source(I) ( j) .available (K) , 

INTERVAL*AVAILABLE„DUpATION) I 

IF  available' duration  < SPECIFIED^DURATION 
THEN  GO  To  ENdISPEC-INTERVAL? 

delay  is  SABSTRACT.RESOURCE  ( I)  ( J>(  I ) • INTERVaI  • 
STApT  ® SABSTRACT.JOBIINTERVAL. START! 

SSPECIfIED1.PROFXLE  (NEXT)  .START  * STEMP  J^ESOURCF 
(I)  (J) .AVAlLABLEtK) .interval. start  - DELAYI 

SSPECIfIFd"^  profile  (LAST)  aEND  a STEMP^RESOURCE 
(I)  (J)",AVAILABLE(K)  .INTERVAL. END  * 
SPECIFIED^OURATION  - DELAY! 

IP  siSPFCIFXFD  PROFILE(LAST)  «.END  < START 

then  prune  SSPECIFIED_PR0FILE(LAST) ! . 

FLSf  if  «5SPECIEIED_PR0FXLE  (LAST)  .start  < 

start 

then  SSPECIEIED„.PR0FILE  (LAST)  .start  * 

START! 


ELSE! 

END! 

end^spec1interval:endi 

/♦  FIND  intersection  OF  STARf«TfME  INTERVALS 

Call  interval_intersect(sintersection_specifieo» 

$SPECIFIED„PR0FILE»SINTERSECT) s 
graft  SINTERSECt  at  $INTERSECTI0N„SPECXFIEDI 


#/ 
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/*  PRUNE  THE  SPECIFIED  RESOUf?C£  NAME  FROM  $UNSPECIFIE0_RESOURCE  */ 
prune  sunspecified^resource 

.#LABEt<SABSTRACTeRESOURCE(I) (Uy ) I 
$SPEcIFIED„RESOURCE n ) « NEXT)  » label (SABSTRACT.RESOURCE 
il)  (J) ) ? 

endi 

/*  HAVE  ALL  REQUIRED  RESOURCE  ELEMENTS  BEEN  CONSIDERED?  */ 

END_SEPARATE.SPEClFIEnsEND» 

/*  form  the  next  permutation  OF  available  resources  taken  the  • 

/*  number  required  at  a time  * 

tf  srequired^indices  identical  to  SNuLL 
then  do? 

CALL  lNTERVAL.lNTEpSECT(SINTERSECTlON_INITiAL* 
SlNTERSECTlON„SpECIFTEDtSlNTERSECT) » 

graft  sintersect  at  sintersection_initiali 
endi 

FIND_PERMUTATI0N| 

do  for  all  permutations  of  SUNSPECIFIED_RES0URCE 
TAKEN  NUMBER($REQUTREDliINDIc£S)  AT  A TIME! 

SINTERSECTION  initial  a SRFQUESTED.INTERVALI 
NUMBER«PERmUTATION  = nUmBER^PERMUTATION  * II 

/*  do  the  descriptors  of  required  and  available  resources  match? 

ELEMENT_CHECKl 

DO  J e 1 TO  NUMBER (SREQUIRED-INDICES)  I 
INDEX  a $REQUIReD1INDICES(J) I 
LABEL(SNAME)  = LABEL (SPERMUTATION(U) ) I 
IF  LABEL(SABSTRACT.RESOURCEt  i)  (INDEX)  ) -•=  *» 
then  go  to  END„ELEMENT„CHECK} 

ELSE  DO  K = 1 Tn  NUMBER (SABSTRACToRESOURCE  (I) (INDEX)) I 
DO  L a 1 TO  nUMBER($TEMP1rES0URCE(I) «#LABEL(*NAME) • 
AVAILABLE)! 

IF  ( SABSTRAcT.RESOURCEd) (INDEX) (K) .DESCRIPTQR(I) • 

INITIAL  subset  qF  STEMPIrESOURCE ( I ) ,#LABEL <«NAmF 
) .AVAli'A0LE(L)  ,DESCRIPT0R(U  ^INITIAL  I 
STEMP^RESOURCEd)  ♦^^LABEL(SNAME)  • AVAILABLE  (L)  • 
DESCRIPTOR(I) .INITIAL  SUBSET  OF  SABSTRACT. 
RESOURCE di (INDEX)  <K) , DESCRIPTOR (1 ), INITIAL  ) 

then  go  To  end1element«.check? 
elsei 
Endi 

/♦  have  all  elements  of  this  permutation  been  checked?  ♦/ 

ENDI 

GO  To  NEXT^PERMUTATION? 

end.elementIcheck s endi 

/*  calculate  intervals  of  start  time  */ 

determine^intervalsi 

DO  J * 1 To  NUMBER (SREQUIRED^INDICES) 5 
prune  SAVAIL^PRoFJLEI 
INDEX  a SREQUIRFD_InDICES(J) I 
LABEL(SNAME)  = LABEL ( SPERMUTAT ION ( J ) ) I 
IF  SaBSTRACT, RESOURCE  ( I )( INDEX )(  U . INTERVAL  IDENTICAL 
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N.i'N' 


IF 


To  SNUlL 

CftLL  OuRAf ION (S ABSTRACT .JOB^INTERVAL* 
REQUIRFD^DURATION) ! 

GO  TO  STArT^K^LOOP? 

NUMBERCSABSTpACT. RESOURCE  (I) (INDEX))  > 1 


» 1 TO  NUMBER (SABSTRACT. RESOURCE  (I) (INDEX)) I 
sSeLinT(L)  = fABSTRACT.RESOURCE  (!)( INDEX)  (L)  . 

intervali 

DO^L  = I TO  NUMBER($TEMP.RESOyRCE(IMJ).lN  USE)! 

sassignIinT(L)  = *temp:resource(I)(J).in.use(l). 
intervali 

DO^L  = 1 TO  NUMBER  ($TEMP„RES0URCE  ( I ) (J)  •AVAILARl-Ei  ? 

SaVAIlJnt(L)  = STEMPiRESOURCE(I)(J).AVAlLABLE(L). 

interval? 


end? 

DO  L * 1 
DO  K = 
DELTA 
DO 


TO  number  (SRE(3_INT)  I 

; L TO  number (SAVAll — INT)I  . . 

a $AVAIL1iNT(K> , start  ” $REQ.1NT(L) .start? 
i’l  ■ 1 TO  NUMBER  (SREQ^INT)  ? 

STEmPIINT (LL) 'START  » SREQ . INT (LL) .START  ♦ 

IF  ^STEMP  INT CLL) .start  < START  1 STEmP|tNT 
LL ) START  > END)  THEN  60  TO  MEXT.TRIAL?^ 
STEmP  INT(LL)*END  a $REQ«INT (LL) .END  ♦ DFLTA? 
IF  fTEMPllNTCLL) .END  > END 
then  go  to  NEXT^TRIAL? 


CALL  InTERVAlIinTERSECT (STEMP^INT*SASSIGN«1mT 

.SInTERSECT)? 

IF  SINtERSECT  identical  TO  SNULL 
THEw  DO? 

"no  KK  = 1 TO  NUMBER(SAVAIL^INT) ? 

DO  LL  = 1 TO  NUMBER($TEMP„INT) ? 

WINDOW  = SAVAII INT (KK). End  - 

STEMP^INT(LL) .end? 

IF  WINDOW  >=  0 

THEN  SWIND0W„SET(NEXT)  a WINDOW? 
END? 


FND?  ^ iw  • 

CALL  FINDlMIN($WINDOW„SET»SINDICES» 

VAL^MIN)?  f 

SAVAIL.PROFli  E(NEXT)  .START  » STEMP^INTU). 

Start i 

$AVAXL  PROFli'E(LAST)  .end  « VAL^MlN 

$tfmp1int(1) .start? 

GO  TO  NEXT-TrIAL? 
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fnd? 

‘ ELSf? 

NEXT^TrIALJ  end? 
end* 
end? 

ELSE  CALL  DURATION (SABSTrACT, RESOURCE  ( I ) ( INDEX ) M ) . 
INTERVAL»REQUIRED1dURATION) I 
/♦  DELETE  intervals  WHICH  ARE  TOO  SHORT  */ 

start1k_loop« 

DO  K » 1 TO  number  (fTEMPiiRESOURCE  (I)  .#LABEL(SNAME)  . 
AVAILABLE)? 

Call  duration (stemp.resource (d .#label($name)  • 

AVAILAbLE<K) •iNTERVALtAVAILABLE^DUpATION) ? 

IF  AVAILABLE&DURATION  < required^duration 
Then  go  To  endIinteRVAl? 

ELSE  DO? 

DELAY  a !SABSTRACT.RES0URCE(I)  (INDEX)  (1)  . 

Interval. START  - sabstract. jobIintervai'. 
Start? 

SAVAIL’' PROFILE  (NEXT)  .start  » STEMP^PESOURCE 
(I)'!!#LABFL(*NAME)  .AVAILABLE(K)  .interval, 
start  - delay* 

SAVAIL^ PROFILE (LAST) .END  = $TEMP_RES0URCE ( T ) 
.#LaBEL (|NAME) .available (K) oINTEPVaL.ENO  - 
REOUIRBOI’DURaTION  - DELAY? 

IF  SAVaIL^PROFilE (LAST) .END  < START 
them  prune  *aVa!:L_PROFILE  (LAST)  ? 

ELSf  if  SAVAIL»PR0FILE (LAST) .start  < STArT 
then  «AVaIL.PROFILE(LAST) .start  « STapT? 
ELSE? 

END? 

END«lNTERVAL:ENn? 

/»  find  intersection,  of  start-timf  intervals  */ 

Call  lNTEpVAi_INTERSECT($INTERSECTlON«INITIAL» 
SAVAIL_PRoFILE9SINTERSECT) ? 

GRAFT  SINTERSECT  AT  SINTERSECTION.INITIAL? 
STEMp1aSSIGN{|)  (NUMBER-PERMUTATION) .resource  J^AME (J)  « 
label (SPEpMUTATION(U) ) ? 

END? 

/*  INCLUDE  SPECIFIED  RESOURCfS  IN  INTERVAL  FOR  THIS  PERMUTATION  */ 
CALL  INTERVAL^INTEpSECT (SINTERSECTION.INITIAL* 
SINTERSECTION.SpECIFIED,$INTERSECT) ? 

GRAFT  ^intersect  AT  $ImTERSFCTION_INITI AL ? 

LaBEL(STEMP«ASSI6N(I) ) = LABEL($A0STRACT.RESOURCF(I) ) t 
STEMP^ASSlGNitl)  (^UMBER-PERMUTATION)  .INTERVAL  = 

$intersection1:initial? 

/*  have  all  permutations  of  available  resources  of  this  type  bfen  */ 
/#  considered? 

next.permutationsend? 

/#  has  at  least  one  interval  bfen  identified? 

IF  NumBER^PERMUTATTON  s 0 then  do? 
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call  INTERVAL.InTERSFCKSINTERSECTION.INITIAL* 
SINTERSECTIONIi^PECIFIED.SINTERSECT)  I 
graft  SINTERSECT  AT,«UNIONa)» 
so  TO  next.resourceItype* 
enoi 

ELSfJ 

DO  NP  = 1 TO  NUMBEp(STEMP_ASSIGN(I) ) 

IF  fTEMP.ASSlGN(I)(NP) .interval  IDENTICAL  TO  $NULL 
THEN  GO  TO  NEXtC:TEMp1aSSiGNI 

Else  oot 

/*  FIND  THE  union  OF  INTERVALS  FOR  THIS  RESOURCE  TYPE  •/ 

SDUMMY.INTERvAL  = STEMP^ASSIGNCI) (NP) .INTERVAL! 


CALL  INTERVAL.UNIOm($UNTON(I) » SDUMMY^I NTERVAL # 

SINT^UNION) » 

graft  SINTIuNION  at  SUNION(I)! 

Enoi 

next_tfmp.assign:  end? 

/•  HAVE  ALL  resources  OF  THIS  TYPE  BEEN  CONSIDERED?  « 

/*  HAVE  all  resource  TYPES  0FEN  CONSIDERED?  * 

NEXT.RESOURCE^TYPEtENO? 

/•  FIND  THE  INTEpSECTTON  OF  INTERVALS  FOR  ALL  RESOURCE  TYPES  */ 

DO  I = 1 TO  NUMpER(SUNION) I 

call  INTERVALl.lNTERSECT(?INTERSECTlON_FlNAL»SUNrON{I) t 
SINTERSECT)? 

graft  sintersect  at  SINTfRSECTIONlFINAL? 

END! 

/*  insert  THIS  interval  AS  SaVAILABLeLwINDOWS. ANY^RESOURCE^SET  #/ 

SAVAlLABLE_WlNDOWS,ANY„RESOURCE'fSET  s SINTERSECTfON.FINAL? 

/*  DETERMINE  RESOURCE  SET  WITH  EARLIEST  START  TIME  */ 


FIND_RESpURCE_TYpEl 

SEGIN.TIME  e SlNTERSECTInNlrrMALd)  .start? 

END_TIME  » SImTERSECTION- FINAL (1) .end? 

assignItype? 

DO  I « 1 To  NUMBER($TfMP_ASSIGN) ? 

ASSIGN.PERMUTATI0N_NUm8ERI 

DO  J = 1 To  NUMBER($TEMp1assIGN(I) ) I 
ASSIGN^INTERVALI 

DO  K = 1 TO  NUMbER($TEMP^:ASsIGN(I}  (J)  .interval  )? 

/#  FIND  INTERSECTION  OF  InTEpVaLS  FOR  THIS  RESOURCE  SET  WITH  */ 

/*  intervals  FOR  ALL  SETS  AND  INSERT  aS  TAVAILABLE^WINDOWS.SAMeIsfT  */ 

IF  BEGIN^TIMF  >=  STEMP^SSIGNd)  (J)  .INTERVAL  (K).sTART 
5.  BEGIN.TiME  <=  STEMP.ASSiGNd)  (J)  .INTERVAL  (K)  .END 

Then  if  endItime  > stemp_assign(I) (j) .interval'  (K), 

END 

THEN  Dp? 

ENDITIME  « STEMP_,ASSr6Nd)  (J)  .interval  (i<>  . 
pND? 

SINtErIa^SIGNCI) .RESOURCE  = 

“STEMp^ASSjGNd)  (J)  .RESOURCE^NAME? 
LABfL(SINTER<;ASSIGNCI)  ) « LABEL  (STEMP^ASSIGn 
(I)  ) ? 
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SlNTER-ASSlGWnj  , INTERVAL  « 

UTEMP^ASSlGNd)  (J)  .INTERVAL  (1)1 
DO  mS  * T to  number (SSPECIFIED.RESOURCE ( T) ) » 

$INTER' ASSIGN(I) .RESOURCE(NEXT)  = 
SSPECIPIEDIrESOURCE(I)  (NS) I 

fndi 

ENOi 

ELSE  IF  $INTER_aSSI6N(I) .RESOURCE  IDENTICAL  TO 
SNULL 
them  D0» 

«IMTEP  ASSlGN(I) .RESOURCE  * 

STFMP"  aSSIGN(I)  <J)  o RESOURCE., NAME  I 
LABEL($INT£R-.ASSIGN(1)  ) = 

LABEL(STEMP..ASSIGN(I)  ) I 
flNTERlASSlGN(I) .INTERVAL  = 

STFMPIaSSIGN(I)  (J)  ^INTERVAL  (D« 
no  NS  = 1 TO  NUMBER (SSPECIFIED_RES0URCE) I 
SIMTEr' ASsIGN(I) .RESOURCE(NEXT)  x 
$SPfCIFIED_RESOURCE(I) (NS) I 

END? 

FNDI 

ELSf? 

ELSE! 

END! 

END! 

END! 

complete' SAME.SETS 

$SaME_SET  X SINTERSECTIOm„FINAL! 

DO  I X 1 TO  NUMBER(STEMP* ASSIGN) ; 

CALL  INTFRVAL1iNTERSEcT($SAME1sET,SINTER„ASSI6N(I) .INTERVai  » 
SINTeRSECT)! 

graft  SINTERSECT  AT  SSAME.SET? 

END! 

SAVAILABLE_WInDOWS.SAME_pESOUPCE1sET  = $SAME_SET! 

CONSTRUCT  SCONCRETE  « 

GRAFT  SABSTRAcT  AT  SCONCpETEI 
DO  I X 1 TO  NUM6ER(SInTEr_ASSTGN) I 

DO  J = 1 To  NUM8ER($RFQUIRED_INDICES) S 
index  « $RE0UIRED.^TNDICES(J)  ! 

LA8EL(SC0NCRETE*RES0URCE(I) (INDEX) ) = SINTER^ASSIGN ( I ) . 
RESOURCE (J) ! 

END!  _ 

DO  FOR  ALL  subnodes  Of  SCOMCRE JE^RESOURCE ( I ) USING  SCONJINAmE! 
DO  FOR  ALL  SUBNODES  OF  SCON?!i:NA*'4E  USING  iSUB^NAME! 

SSUB^NAME. interval. START  ~ SSUB_NAME . INTERVAL .START  ♦ 
$INTFR_ASSI6N(T) « interval. START! 

SSUBInamE. interval .END  « SSUBInAME. INTERVAL, END  ♦ 
SINTER_ASSI6N(T ) .interval. ST ART! 

END! 

END! 


SC0NCRETE#J0B_1NTERVAL. start  « SC0NCRETE.J0B_INTERVAL. START  ♦ 
SSAME..SET  (FIRST)  • START  I 

sconcrete.job_interval.end  b sconcrete.job^interval.end  ♦ 
5SAME.SETIFIRST) .STARti 

SCONCRETE.UNAVAIL^TIME  = SAVAILABLe1wIND0WS.SAME_RES0URCE_SET(1)  .'ENni 
LABEL  (SCONCRETE),=  »SC0NCREtEM 

LABEL(SAVAlLABLEiwiNDOWS)  a • SAVA ILABLE^W INDOWS M 
END.NEXTSETI  END I 
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2.4.13  RESOURCE  PROFILE 


2.4.13  RESOURCE_PROFILE 


2.4.13  RE  SOURCE_PROFILE 

2.4.13.1  Purpose  and  Scope 

1 

In  project  scheduling  the  resources  are  assigned  from  a pool 
and,  upon  completion  of  the  job,  are  returned  to  the  pool  of  avail- 
able resources.  Thus,  the  quantity  of  a given  resource,  available 
in  the  pool  for  a given  time  interval,  is  required  to  determine 
the  advisability  of  scheduling  a given  job  at  a given  time.  Fur- 
ther, if  sufficient  resources  are  not  available  at  the  desired 
time,  a contingency  level  of  resources  may  be  considered.  This 
module  determines  the  profile  of  available  resources  over  a given 
time  interval  for  both  a "normar'  and  '’contingency”  level  of  re- 
source. If  contingency  levels  are  not  to  be  considered,  they  are 
set  equal  to  the  normal  level.  Certain  functional  characteristics 
of  project  scheduling  also  create  the  need  to  determine  the  usage 
of  a pool  assigned  over  a given  interval  (such  as  in  attempts  to 
level  resource  usage).  Therefore,  this  module  also  determines 
the  profile  of  the  assigned  portion  of  the  pool  and  defines  the 
association -of  jobs  that  make  up  the  usage  profile. 

2.4.13.2  Modules  Called 
None . 

2.4.13.3  Module  Input 

The  input  to  this  module  will  consist  of  that  portion  of  the 
$RESOURCE  tree  for  the  pooled  resource  type  and  name  whose  profile 
is  to  be  generated.  This  is  the  substructure  of  a second-level 
subnode  of  $EE SOURCE,  and  is  referred  to  as  $RESOURCE_NAME . Further 
input  will  consist  of  the  time  interval  for  which  the  profi;Le  is 
to  be  generated,  $EEQUIRED__INIERVAL . 
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2.4.13.4  Module  Output 


The  output  of  this  module  will  consist  of  a tree  structure  as 
shown  in  the  sketch.  The  INJJSE  portion  of  the  tree  defines  the 
quantity  of  the  pooled  resource  assigned  to  a job  for  a given  time 
interval.  Therefore,  the  sum  of  the  quantities  for  a given  inter- 
val define  the  total  INJJSE  resources  for  that  interval.  The  span 
of  intervals  listed  will  be  consistent  with  the  input  interval  re- 
quested. The  available  portion  of  the  tree  defines  the  quantity 
of  resource  pool  that  is  unassigned  for  both  a normal  and  contin- 
gency mode  of  operation.  These  quantities  are  determined  from 
the  initial  levels  defined  in  $RESOURCE,  the  allocations  recorded 
in  the  ASSIGNMENT  portion  of  $RESOURCE,  and  the  resources  DELETED 
or  GENERATED  recorded  in  the  ASSIGNMENT  portion  of  $RESOURCE. 


$PR0FILE 
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(value)  (value) 


2.4.13.5  Functional  Block  Diagram 


2.4.13-3 


Rev  A 


9 

Define  complement 
as  current  interval. 
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2.4.13.6  Typical  Applications 

This  module  would  be  used  to  determine  availability  of  re- 
sources for  project  scheduling,  or  as  a potential  output  to  a 
user  or  scheduling  heuristic  that  was  attempting  to  allocate  re- 
sources in  a predetermined  manner. 
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2.4.13.7  DETAILED  DESIGN 


This  module  first  checks  the  standard  data  structure,  $RESOURCE, 
to  determine  any  assignments  of  the  requested  resource  element  during 
the  time  period  of  interest.  If  there  are  none,,  a message  is  written 
and  control  is  returned  to  the  calling  program.  The  earliest  assign- 
ment about  the  input  start  time  is  located  and  defined  as  the  "current 
interval."  The  start  of  the  current  interval  will  never  be  earlier 
than  the  input  start  time. 

All  other  assignment  intervals  are  compared  x^ith  the  current 
interval,  and  non-null  intersections  are  placed  in  $ASSIGN_SET.  The 
start  and  end  times  of  the  intersections  are  also  placed  in  $TKMP__SEI, 

The  times  in  $TEMP_SET  are  then  ordered  and  non-equal  pairs  are  used 

to  construct  the  subnodes  of  $PROFILE,IN_USE,  Job  usage  and  quantities 
are  then  added  to  the  INFUSE  subnode. 

If  any  resources  are  generated  or  deleted  during  the  assignment 
under  consideration,  as  noted  by  a change  in  quantity  from  initial 
to  final,  the  deltas  are  added  to  the  INITIAL__PR0FILE  subnode  for  both 
normal  and  contingency  usage. 

The  complement  of  the  next  assignment  with  respect  to  the  current 

interval  is  developed.  If  this  complement  is  not  null,  it  is  defined 

as  a new  "current  interval."  If  this  new  current  interval  is  within 
the  time  period  of  interest  the  process  is  repeated!,  ptherwise,  the 
available  tree  structure  is  developed  by  subtracting  the  in  use  portion 
from  the  initial  profile. 
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The  functional  block  diagram  can  be  used  as  a module  flowchart, 
2.4.13,8  Internal  Variable  and  Tree  Name  Definitions 

delta  - The  number  of  a given  resource  element^ 

either  generated  or  deleted  during  an 
assignment, 

QUAN_USE  - The  total  number  of  a resource  element  in 

use  during  a given  IN_USE  interval. 

$ASSIGN_SET  - A data  structure  having  the  form  of  the 

ASSIGNMENT  node  in  $RESOURCE  but  with  the 
interval  set  equal  to  the  intersection 
with  "current  interval". 

$ASSIGNMENT  - A pointer  to  each  subnode  of  the  ASSIGN- 

MENT node  in  $RESOURGE. 

$BUILD__PROFILE  - A single  node  tree  used  as  a flag  to  spec- 
ify whether  or  not  to  construct  the  initial 
profile, 

$COMPLEMENT  - Output  interval  from  internal  procedure 

interval_complement  , 

$CURRENT__INTERVAL  - Output  interval  from  procedure  INTERVAL_ 

INTERSECTION, 

$TEMPJR.E SOURCE  - A temporary  data  structure  equivalent  to 

$RESOURCE  but  for  only  the  single  resource 
element  being  considered, 

$TEMP  SET  - A set  of  start  and  end  times  of  non-null 

intersections  of  assignments  with  "current- 
interval" 
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2.4.13.9  Commented  Code 


R|ES0URCE«.PR0FIUE*  procedure  (SrES0URCE1nAME#SREQUIRED«INTERVAL» 

SPROFILE)  OPTIONS(EXTERnAL) I 
OfeCLARE  SBUILD^PROFILE  LOCALI 

DiCLARE  MMt«ASSl6NMENT#*ELEMEMT  LOCAL!  . 

declare  I,J*K#LtKK*LLfDELTA.QUAN„USE*SASSIGN.SET*SCOMPLEMENT  LOCAL! 
declare  SCURRENt’ lNTERVALtSINTERSp:CT*STEMP_RESOURCE*$TEMP.SET  LOCAL! 
LABEL (SPROFJLE)  * LABEL (SRESOuRCEMnAME j I 
$|UILD«PR0FILE  b ‘YESM 

/*  IS  requested  interval  consistent  with  data  in  SRESOURCEt  */ 

IF  SREQUIREO^INTERvAL.END  < SrESOURCE_NAME*INITIA( — time 

^^^WRITE  'INTERVAL  REQUESTED  PRIOR  TO  RESOURCE  AVAILABILITY*! 

return? 

END!  - 

ELSE  IF  $REQUIRED«,INTERVAL.END  < SRESOURCE^NAME* ASSIGNMENT (FIRST) • 

interval."start 

THEN  DO! 

write  'INTERVAL  REQUESTED  PRIOR  TO  FIRST  ASSIGNMENT*! 
SPROFILE.AVAXLABLE  * SRESOURCE-NAME.INITIAL.PROFILE! 

RETURN! 

END! 

IF  SREQUIRgD^INTERVAL.START  > SRESOURCE-NAME.ASSIGNMENT (LAST) .InTERVAI 
.END 

THEN  DO!  _ 

WRITE  'INTERVAL  REQUESTED  IS  LATER  THAN  LAST  ASSIGNMENT'! 

RETURN! 

END! 

ELSE  STEMP-RESOURCE  * SRESoURCE„NAME!  . , • 

/#  LOCATE  THf  earliest  ASSIGNMENT  INVOLVING  THE  INPUT  START  TlME.^  * 
/•  COMPUTE  PORTION  OF  THAT  ASSIGNMENT  INCLUDED  IN  REQUESTED  INTERVAL.* 
/*  call  it  'CURRENT  INTERVAL*.  * 

DO  I ■ 1 TO  number (STEMP^RESOuRCE. ASSIGNMENT) ! .. 

IF  STEMP,RE.SOURCE.ASSIGNMEnT(I) .interval. end  > SREQUIRED«INTERVAL. START 
THEN  If  STEMP  resource. assignment { I) .INTERVAL. END  <• 
SREQUIREDIINTERVAL.EnD  ^ 

THEN  IF  STEMP^RESOURCE. ASSIGNMENT (1) .interval. START  <* 
SREQUIREDIiNTERVAl. START 

^^^SCURRENT^INTERVAL. START  « SREQU IRED.INTERVAL.START ! 

SCUrrENT.INTERVAL.END  = fTEMP^RESOURCE.ASSIGNMENTd) . 

interval, ENO! 

GO  TO  POINT^B! 

END! 

^*"^SCURRENT*INTERVAL  « $TFMP1rES^OURCE.ASSIGNMENT(  I)  .INTERVAL! 
GO  TO  POINTER! 

END! 

ELSE  IF  STEMP^RESOURCE.ASSlGNMENTd)  .INTERVAL, START  < 
$REQUIRE0_INTERVAI .END 
THEN  DO! 


SCURPENT«,INTERVAL. START  = sTEMP_RESOURCE* ASSIGNMENT ( I ) . 
INTERVAL*ST'aRT» 

SCURRENT^INTERVAt.END  a SREQUIRED^INTERVAL.ENDI 
GO  TO  POINT^BI 
ENDI 
ELSE» 

ELSEI 

END! 

/•*  FORM^AN  assignment  SET  CONSISTING  OF  ALL  NON-NULL  INTERSECTIONS  »i 
/*  OF  assignments  WITH  THE  »CURRFNT  INTERVAL*. 

POINT^Bi 

PHUNE  SASSIGN.SETI 

nn  I X 1 To"”nUMBER  ( STEMP  RESOURCE. ASSIGNMENT)  I 

CALL  INTERVAL^INTERSECT <iTEMPfeRESOURCE. assignment (J) .INTERVAL* 

SCURRENT*  INTERVaL»SINTERSEOT> S 

IF  sintersect  identical  to  snull 
then  go  to  END-L00P«JI 

^*"^lF*^*INTERSECT(Ki!!sTARVx^SlNTE^  ENOtfKii  OOP? 

SASSIGN_SET(NEXTj  » STEmpIRESOURCE. ASSIGNMENT (J) » 

«SsTgSeT®lUt  K iStEUiLtENfs^STEiS^^  . ASSIGNMENT  I J)  . 

THEN*^SASSIGN^SET (LAST) .descriptor (LAST) oFINAL. quantity  s 

STEmP.RESOURCE. assignment (J) .DESCRIPTOR(LAST) .initial. 

quantity? 

STEMP..SET  (NEXT)  * SInTERSECT  (K)  .START? 

STEMP^SET(NEXT)  * SImTERSECT(K) •ENOI 

STEMP«SET(NEXT)  * $ImTERSFCT(K).END» 

End^k^loop:  end? 

/^'’"bS?['''a  IubJoDE  of  IN.USE  FOR  FACH  INTERVAL 

/•  START  and/or  END  TIMES.  ADD  CORRESPONDING  JOBS  AND  QUANTITIES  / 
/*  FOR  THE  ASSIGNMENT  SET. 

ORDER  STEMP.SET  PY  -SELEMENTI 
DO  J = 2 TO  NUMBFp(STEMP_SET) I 
IF  STEMP_SET(J“1)  = $T|NP_SET(J) 

THEN  GO  TO  EN0.L00P_J2I 

^^^»profile.in-.use (NEXT)  .Start  c $temp„seT(j-d  i 
$profile.in^use(lasT) .End  « $temp„set(J) i 

do  K a 1 TO  number  (SASSIGN-SET);  tkiTfRVai  «TApT 

IF  $PROFILE.IN_USE(LAsT). START  >=»  ^^^SION  SET (K). INTERVAL. START 

THEN  IF  $PRpFlLE.lN«USE(LAST) .END  <«  SASSIGN.SET (K ) • 

’^^*PROFiLE?iN|uSE'(LAST).USAGE(NEXT),JOB  « *AS,SIGN|sET 

(K) .JOB  TO I „ ^ 

no  L » 1 TO  NUMBFR(SASSI6N„SET(K). DESCRIPTOR  )l 
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SPROFILE. INFUSE (LAST) .USA6E(LA$T) .QUANTITY  ■ 

*profile.in.use(last> .usage(last) .quantity  ♦ 
SASSIGN.SET(K) .OESCRIPTOR(L) .initial. ouantityi 
ENDl 
ENOI 

END  I 
ENOt 

END.LOOP_J2l  ENOI 

/*  ARE  ANY  RESOURCES  GENERATEo  OR  DELETED  IN  ASSIGNMENTS  CONSIDERED? 

IF  $BUILD_PROFIlE  « »YFS«  THEN 

DO  FOR  ALL  SUBNOOES  OF  STEMP^PESOURCE, ASSIGNMENT  USING  SASSIGNMENTl 
SBUILO.PROFILE  « »NO*| 

delta  * 01 

DO  L ■ 1 TO  NUMBER($ASSI6NmENT  .DESCRIPTOR) I 

IF  ^assignment  .descriptoR(l) .final. quantity 
identical  to  snull 
Then  go  to  fnd.loopj.i 

ELSE  delta  » delta  ♦ SArSIGNMENT  .DESCRIPTOR (LT. FINAL. 

quantity  -r  SASSIGNMENT  .DESCRIPTOR (L) . INITIAL. QUANTITYI 
END»L00pLl:  ENOI 

IF  delta  a 0 then  go  to  eno.ldop.ki 

/*  ADD  deltas  to  INITI AL-PROfIlE  AND  STORE  AS  TOTAL.  */ 

DO  L = 1 TO  number (*TEMP_RFS0URCE.INITIAL.PR0FILE. NORMAL) I 
IF  STEMP^RESOURCE, INITI AL.PROFILE. normal (L) .START  >■  SASSIGNMENT. 

interval  .’end 

THEN  $TEMR_.RESOURCE.INItIAL!:PROFILE.NORMAL(L)  .QUANTITY  a DELTA  i 
STEMP.RESOURCE. INITI AlIpROFILE.NORMAL(L) .QUANTITYI 

else  if  stemp.rfsource. INITI al>rofile. normal (L) .end  > 

SASSIGNMENT. interval. end 
THEN  DO! 

STEMP_RES0URCE.INITIAL1pR0FILE,N0RMAL(L+1) .START  * 
SASSIGNMENT, interval. end  I 
STEMP.RESOURCE. initial  PROFILE. NORMAL (L^l ) .END  * 
STEMP.RESOUrCE.INITIAL.PROFILE. normal (L) .ENDl 
STEMP.RESOURCE. INI TIALIpROFILE, normal (L+1) .QUANTITY  • 
STEMP.RESOUrCE. INI TJAL.PR0FILE. NORMAL (L) .QUANTITY! 
STEMP.RESOURCE. INITIAL.PROFILE. NORMAL (L»l) .QUANTITY  » 
STEMP_RES0UpCE.IWITIAL.PR0FILE*N0RMAL(L*1) .quantity  i 
DELTA! 

STEMP.RESOURCE, INITIAlIpROFILE. NORMAL (L) .END  = 
SASSIGNMENT. interval. ENOI 
ENDl 
ELSEI 

ENOI 

DO  L a I TO  NUMBER(STEMP.ReSOURCE.INITIAL.PROFILE. CONTINGENCY) I 
IF  STEMP_RES0URCE.INITIAL.PR0FILE.C0NTINGENCY(L) .START  >a 
SASSIGNMENT. interval. END 

then  STEMPlRES0URCE.INltlALlPR0FlLE.C0NTIN6ENCY(L) .quantity  « 
STEMP.RESOURCE.INITIalIpROFILE.CONTINGENCY(L) .quantity*  ofUTaI 
ELSE  IF  STEMP-RESOURCE.iNlTlALlPROFlLE.CONTINGENCY(L) .end  > 
SASSIGNMENT. interval. END 
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then  do» 

STEMP.RES0URCE.INITIAL1pR0FILE«C0NTINGENCY(L*1) .start  « 
sassignment, interval, end? 

STEMP.RESOURCE.INITIAL_RROEILE.CONTINGENCY(L^1) .END  ■ 
$TEMP_RESOUpCE,INITIAL„PROFILE. CONTINGENCY (L) .END  I 

STEMP^RESOURCE. INI TIAlIpROFILE. CONTINGENCY (L*l ) , 

QUANTITY  = fTEMPlRESOURCE.lNITIAL^PROFlLF. 
CONTINGENCY(L) .QUANTITY! 

*TEMP^RES0URCE„ INITTAlIpROFILE. CONTINGENCY (L^l ) .QUANTITY 
= $TEMP«RESoUReE.INITlALfepR0FlLE.C0NTIN6ENCY<L*i) . 
quantity  ♦ QELTA! 

STEmP^RESOURCE, iNITIALipROFiLE. CONTINGENCY <L) .END  * 
SASSIGNMfNT.INTERVAL.^NO! 

END! 

elsei 

END! 

END_LOOP_Kl  END! 

/*  TAKE  complement  OF  NEXT  ASSIGNMENT  WITH  RESPECT  TO  »CURRENT  */ 

/♦  interval* • */ 

take.complement: 

I = I ♦ 11 

IF  STEMP.RESOURCF.ASSIGNMENT(I)  identical  to  snull 

then  go  to  buildItree? 

CALL  INTERVAL-COMPLEMENT ( SCURrENTLinTeRVAL 9 STEMP^RESOURCE. ASSIGNMENT ( I ) 


.INTERVAL9SCOMPLEMENT) ! 

/*  IS  complement  null?  */ 

IF  scomplement  identical  to  SnULL 

THEN  GO  TO  TaKE^COMPLEMENT | 

/**  DEFINE  complement  AS  ’CURRENT  INTERVAL*.  */ 

SCURRENT^INTERVAL  = SCOMPLEMENT! 

/*  IS  ’CURRENT  INTERVAL’  END  TIME  > REQUESTED  END  TIME?  •/ 

IP  scurrent.interval.end  <*  srequiredIinterval.end 
then  go  to  POINT-B! 

/*  define  *CURRENT  INTERVAL’  END  TIME  » REQUESTED  END  TImF.  ♦/ 

$CURRENT„INTERVAL.END  a SREQUtREO^TNTEP.VAL.END? 

/♦  IS  ’current  interval*  end  time  > start  time? 

IF  SCURRENT^INTERVaL.END  > SRFQUIRFO^INTERVAL. START 
THEN  60  TO  POINT-0! 

/*  SUBTRACT  the  IN-USE  PROFILE  FROM  TOTAL,  #/ 

/*  BUILD  available  TREE  STRUCTURE.  */ 

build.treei 

00  KK  » 1 TO  NUmBER($PR0FILE*In1USF) I 


DO  LL  * 1 TO  number (STEMP-PESOURCEoINITIAL„PROFILE. NORMAL) ! 

IF  SPROFILE.IN-USE(KK) .start  >s  STEMP-RESOURCE.INITIAL’'pROFILE. 
NORMAL (LL) .START 

Then  if  $PROfILE.IN«.USE(KK)  .end  <=  STEMPlRESOURCE.lNITIALlhPROFli'E 
.NORMAL(LL) .END 
THEN  DO! 

SPROFIlE. available. NORMAL(KK)  a SPROFILE.IN^USE(KK) f 
prune  SPROFILE. AVaILARLE.NORMAL(KK) .USAGE! 

OUAnIUSE  a 01 
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00  mm  * 1 TO  NUM0frR(SPROFlLE.IN_USE(KK)  .USAGE)  I 
QUAnIUSE  ■ QUAnIusE  ♦ «PR0FILE.IN_USE(KK) .USAGECMM) , 

quantity  I 

ENDl 

SPROFILE. available. NORMAL(KK) .quantity  ■ STEMP.RESOURCF. 

INITIAlIpROFILF.NORMAL(LL) .QUANTITY  - QUAN.USEI 
GO  TO  BUILO^CONTImGENCYI 
ElVOl 

ELSE  60  To  END.LL_LOoPl 
else  I 

ENDa.L^^LOOPl  end  I 
BUILD.CONTINGENCY I 

DO  LL  a 1 TO  NUmBER($TEMP.pESOUPCE.INITIAL_PROFILE. CONTINGENCY) I 
IF  SPROFILE.IN.USE(KK) .start  >«  $temp«resource.initial.profile. 
CONTINGENCY(LL) .START  . . 

Then  if  $PR0FILE.IN«USE(KK) .FND  <*  STEMP^RESOURCE.lNITlALiPPOFU  f 

.contingency  (LL)  .E^ND 

THEN  DOI 

SPROFILE. AVAILABLE. CONTINGENCY(kK)  * SPROFILE. INFUSE (KK) I 
PRUNE  JPROFILE.AVaILABLE.CONTInGENCYCKK) .USAGE! 

QUAN^USE  s 01 

00  MM  « 1 TO  NUMBfR(SPROFIlE.IN_USE(KK) .USAGE) I 
QUAN.UsE  » QUAN.USE  ♦ f PROFILE. IN_USE (KK) .USAGE (MM) , 
QUANTITY! 

ENOl 

SPROFILE. available. CONTINGENCY(KK) .QUANTITY  * 
$TEMP^ESOURCE.INlTIAL_PROFlLE.CONTINGENCY(LL) .QUANTITY 

- «uan;.use» 

GO  TO  EN0_KK_L00P| 

END! 

ELSE  60  To  END.LOOPJ'lI 
ELSEI 

end.loop_ll«  end  I 

END„KK_L00P*  ENDl 

IF  SPROFILE. available. NORMaL(FIRST) .START  > SREOUIRED.INTERVAL.STAPT 
THEN  DO!  ^ 

INSERT  $RESOURCELNAME.InITIAL_PROFIi  E.NORMAL(FIRST)  BEFORE 
SPROFILE. AVAILABLE. NORMAL (FIRST) ! 

SPROFILE. available. normal (FIRST) .START  = SREQUIRED.lNTERVAL.STARTt 
SPROFILE. available. normal (FIRST) .END  a SPROFILE. AVAILABLE. NORMA) 
(2) .STaRTi 

END! 

IF  SPROFILE. available. CONTINGfNCY(FIRST) .START  > SREOUIREO.InTERVai 

•start 

THEN  DO!  ■ . . 

INSERT  sresource'  name.initial.profile.contingencY(First)  before 
SPROFILE.AVAILABLF.CONTINGENCY(FIRST) ! 
SPROFILE.AVAILABLE.CONTtNGENCY(FIRST) .start  * $RE15UiRE0«INTERVA| 
.STarTi  . .. 

SPROFILE. available. CONTtNGENCY(FIRST) .END  = SPROFILE. AVAIlABI  E. 

contingency (2) .START! 


2.4.13-12 
Rev  C 


ENDt 

IF  SPROFILE. available, NORMALii'AST) .END  < SREQUIREO^INTERVAL.END 
then  001 

STEMP  = $PPOFILE.AVAILAbLE,NORMaL(LAST) .ENDI 

SPROFILE. available. normal (NEXT)  * $resource«name, initial.profIlf. 
NORMAL(LAST) I 

SPROFILE. available, NORMaL(LAST) .start  » STEMPI 

SPROFILE. available. normal (LAST) .end  ■ SREQUIRED^INTEPVAL.ENOI 

ENDI 

IF  SPROFILE. available, CONTINGfNCY(LAST) .END  < srequired.interval.end 
then  doi 

STEMP  * SPROfILE.AVAILABLE.CONTInGENCY (LAST) .END! 

SPROFILE. available. contingency (NEXT)  a SRESOURCE^NAME. 

init I alIprofile. Contingency (LAST) i 
SPROFILE* available. contingency (LaST) .start  b STEMPI 
SPROFILE. available. contingency (LAST) .END  a SREQUIRED.INTERVAL.'ENOI 
ENDI 
RETURNI 

ENDI  /*  RESOURCEIpROFILE  ♦/ 
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2.414  POOLEDJESCRIPTOR 
COMPATIBILITY 


2.4.14  POOLED_DESCRIPTOR_COMPATIBILITY 
2.4.14.1  Purpose  and  Scope 

This  module  identifies  occurrences  of  resource  description 
incompatibilities  that  arise  when  a single  job  is  to  be  added  to 
a schedule  at  a time  equal  to  or  later  than  a set  of  jobs  that 
have  already. been  assigned  (i.e.,  resources  assignments  have  been 
made  in  $RES0URCE  tree).  It  applies  to  jobs  that  require  resources 
from  pools  or  from  partitions  of  pools  distinguished  from  other 
partitions  by  a separate  set  of  explicit  descriptors.  For  exam- 
ple, if  an  activity  is  described  as  requiring  13  laborers  taken 
from  location  A and  the  laborers  are  not  described  (in  $RES0URCE) 
as  individuals,  but  rather  as  a collection  of  originally  undls- 
tinguishable  resources,  then  the  laborers  that  are  in  location  A 
represent  a partition  of  the  pool  distinguished  from  other  parti- 
tions only  by  the  descriptor  'LOCATION'  with  value  A.  Since  dif- 
ferent jobs  may  not  only  change  the  value  of  'LOCATION'  but  may 
also  add  new  descriptors  such  as  'SKILL'  the  partitions  of  the 
original  pool  may  proliferate  as  the  schedule  is  developed.  An 
illustration  of  this  is  shown  in  the  sketch. 
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It  is  important  to  emphasize  that  this  module  applies  to 
pooled  resources  where  different  subsets  of  the  pools  may  acquire 
distinguishing  descriptors.  The  module  applies  directly  to  time 

progressive  scheduling  strategies. 

A time  transcendent  strategy  to  schedule  jobs  whose  required 
resources  are  described  as  pools  with  varying  explicit  descriptors 
must  necessarily  be  a very  complex 'algorithm.  An  algorithm  that 
places  such  a job  on  a timeline  between  two  scheduled  jobs  would 
have  to  resolve  any  descriptor  conflicts  that  occurred  after  the 
assignment  time  of  the  new  job;  it  is  likely  that  this  conflict 
resolution  would  be  done  by  working  progressively  from  the  assign- 
ment time  of  the  inserted  job  to  the  last  assignment  time  in  the 
schedule.  . Thus,  the  conflict  resolution  strategy  is  likely  to  be 
time  progressive  even  within  a time  transcendent  assignment  strat- 
egy. Therefore,  through  repetitive  application,  this  module  will 
have  applicability  to  time  transcendent  algorithms.  The  problem 
classes  to  which  this  module  applies  are  illustrated. 


Time  Progressive 
Assignment  Algorithms 

Time  Transcei 
Assignment  A! 

ident 

Lgorithms 

Item  Specific 
Resources 

Pooled 
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Only 
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Only 
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This 

module 

applies 

Poor  assign- 
ment strategy 
for  this  type 
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this  algorithm 
applies  with 
repeated  calls. 
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This  module  assumes  some  conventions  about  the  structure  of 
the  ASSIGNMENT  node  of  any  resource  that  is  a pooled  resource 
(i.e.,  for  which  the  node  CLASS  has  a value  'POOLED').  A pooled 
resource  that  has  explicit  descriptors  must  contain  a subnode  of 
DESCRIPTOR  for  each  partition  of  the  pool.  Those  partitions  that 
are  being  used  in  the  assignment  interval  are  distinguished  from 
those  not  used  in  the  interval  by  the  appearance  of  the  'INITIAL' 
and  the  'FINAL'  nodes.  Thus,  the  availability  of  a particular 
partition  of  a pool  is  precluded  during  the  assignment  interval 
only  if  that  partition  has  a subnode  of  the  'DESCRIPTOR  node 
labeled  'INITIAL'.  This  convention  is  illustrated  in  the  follow- 


ing structure: 
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The  structure  illustrates  one  assignment  for  the  pooled  re- 
source named  CREWMEN  and  indicates  that  between  14  June  and  28 
June  five  crewmen  were  assigned  (indicated  by  the  appearance  of 
the  INITIAL  node)  and  10  crewmen  were  not  assigned. 

A slight  generalization  of  the  convention  is  required  for  pools 
that  have  overlapping  assignments.  The  sketch  illustrates  the  as- 
sumed structure  of  a portion  of  the  ASSIGNMENT  substructure  for  a 
pool  of  CREWMEN  that  has  been  separated  into  two  partitions  by 
previous  assignments.  Two  assignments  whose  intervals  overlap  are 


shown. 


Note  in  the  illustration  that  the  availability  of  the  crewmen 
in  the  10-man  partition  during  the  overlap  of  the  assignment  inter- 
vals (15  June  through  20  June)  cannot  be  determined  correctly  by 
merely  noting  the  absence  of  the  ‘INITIAL'  node  in- the  first  as- 
signment. This  is  because  that  partition  is  used  in  the  second 
assignment.  Therefore,  the  convention  adopted  requires  that  all 
assignments  whose  intervals  include  the  availability  time  in  ques- 
tion be  considered  in  determineing  the  pool  condition  at  that 
time.  Note  also  that  the  ASSIGNMENT  conventions  for  pooled  re- 
sources permit  the  determination  of  descriptors  by  considering 
only  the  assignments  whose  intervals  include  the  time  in  question; 
unlike  the  case  for  item-specific  resources,  there  is  no  need  to 
work  progressively  through  all  the  descriptor  changes  from  a set 
of  initial  descriptors  to  correctly  determine  the  descriptors  of 
pooled  resource.  (See  the  discussions  in  volume  II  on  pooled  and 
item-specific  resources  and  the  implication  the  corresponding 
conventions  have  on  scheduling  and  unscheduling  using  time  pro- 
gressive and  time  transcendent  strategies) . 

This  module  builds  a tree  that  displays  for  each  conflict  the 
set  of  resource  pool  descriptors  that  exist  because  of  jobs  already 
scheduled  and  those  required  to  be  added  to  the  schedule.  No  in- 
formation on  which  previously  assigned  jobs  caused  the  conflicts 
is  included  because  the  description  of  any  pool  is  a result  of  the 
composite  of  all  decisions  on  resource  and  job  alternatives  that 
have  been  made  throughout  development  of  the  schedule.  The  most 
basic  information  needed  to  resolve  the  conflicts  is  simply  what 
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descriptors  exist  and  what  descriptors  are  required.  This  infor- 
mation is  provided  by  the  output  tree  from  this  module. 

This  module  does  not  write  or  remove  any  assignments  in 
$RES0URCE,  i.e.,  $RES0URCE  is  returned  unaltered.  $RES0URCE  is 
required  by  the  module  to  assess  the  complete  set  of  descriptors 
describing  the  pooled  resources. 

2.4.14.2  Modules  Called 
None 

2.4.14.3  Module  Input 

This  module  is  called  with  two  arguments:  $RES0URCE  and 

$SCHED_UNIT.  $RES0URCE  has  the  general  structure  given  in  para- 
graph 2.4.14.1;  $SCHEDJJNIT  has  the  general  structure  of  a sched- 
ule unit  shown  in  the  following  illustration,  and  is  equivalent  of  a 
second-level  subnode  of  the  stand  data  structure,  $SCHEDULE. 

Note  that  in  $SCHEDJ[JNIT  the  node  labeled  JO B__INTERVAL. START 
must  contain  the  value  of  the  assignment  time  for  the  job  to  be 
inserted. 
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2.4.14.4  Module  Output 


This  module  returns  a structure  called  $P00LED_RES0URCE_ 
CONFLICTS  which  contains  information  about  conflicts  that  would 
result  if  $SCHEDJJNIT  were  assigned  at  its  specified  time.  The 
general  structure  of  $P00LED_RES0URCE_C0NFLICTS  is  illustrated. 


$POOLED_RESOURCE_CONFLICTS 
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Yes 


Build  Output 
Tree  Showing! 
Conflict 
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2.4.14.6  Detailed  Design 


The  functional  block  diagram  provides  a flow  chart  for  this  module. 
Since  the  module  is  developed  for  pooled  resources  with  explicit  de- 
scriptors, a check  is  made  initially  to  determine- that  each  resource 
required  by  the  candidate  job  is,  in  fact,  a pooled  resource.  If  an 
item  specific  resource  is  required,  a message  is  written  identifying 
the  resource  and  control  is  returned  to  the  calling  program.  Each 
previously  scheduled  assignment  of  the  resource  x^hich  includes  the 
assignment  time  of  the  candidate  job  is  identified  and  placed  in  the 
tree,  $ASSIGN.  Each  partition  of  the  required  resource  is  compared 
with  the  available  resource  to  determine;  first,  whether  a sufficient 
quantity  is  available,  and  second,  whether  the  descriptors  and  values 
required  are  included  in  the  available  resources.  If  either  comparison 
fails  a resource  conflict  has  been  identified,  and  a node  is  constructed 
on  the  output  tree,  $P00LEDJR.ES0URCE_C01IE1,ICTS . The  comparisons  are 
repeated  for  all  partitions  and  all  required  resources. 
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2.4.14.7  Internal  Variable  and  Tree  Name  Definitions 


$ AS SIGN 

tree  built  from  $AVAILABILITY  whose 
intervals  contain  assignment  time  of 
candidate  job 

$AVAIL 

identifier  for  each  subnode  of  $ASSIGN 

$AVAILABILITY 

identifier  for  each  subnode  of  $RESOURCE 
(TYPE . (NAME) .ASSIGNMENT 

$CONFLICT_FLAG 

flag  set  to  indicate  resource  conflict 

$DESCRIP 

- identifier  for  each  subnode  of 

$AVAIL. DESCRIPTOR 

$NAME 

identifier  for  each  subnode  of  $TYPE 

$SUBDESG 

identifier  for  each  subnode  of 
$SUBNAME , DESCRIPTOR 

$ SUBNAME 

identifier  for  each  subnode  of  $NAME 

$TEMP_QUAN 

temporary  location  for  $ SUBDE SC . INITIAL. 
QUANTITY 

$TYPE 

identifier  for  each  subnode  of  $SCHED 
UNIT.  RE  SOURCE 
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2.4.14.8  Modifications  to  Functional  Specifications  and/or  Standard 
Data  Structures  Assumed 

For  pooled  resources  with  explicit  descriptors,  each  partition  must 
be  included  in  the  assignment  portion  of  $RE;'-''URCE . Partitions  that 
have  been  assigned  will  be  indicated  by  INITIAL  descriptors,  as  well  as 
FINAL  descriptors.  Partitions  that  are  available  for  assignment  will 
have  only  FINAL  descriptors. 
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2 . A . 14 . 9 Conunented  Code 


DO 

IF 


POOLED  DESCRIPTOR.COMPATIBILITYJ  PROCEDURE (SRESOURCEtSSCHED.UNiT* 
SPOOLED  RESOURCE.CONFLICtS)  OPTIONS(EXTERNAL) I , nrAi  . 

declare  $ASsTGNtSTYPEfSNAMEf$AVAlLABlLlTY,$SUBNAME*$SUBDESC  LOCALl 
DECLARE  $C0NFLICT«FLA6t$AVAlL;$DESCRIP.STEMP  QUAN  LOCAL! 

DO  FOR  ALL  subnodes  OF  SSCHEDtUNiT. RESOURCE  USING  STYPEI 
FOR  ALL  SUBNODES  OF  STYpE  USING  SNAmE! 

$RES0URCE,#LABEL(STYPE).#LABEL.<SNAME), CLASS  « tSPECIFiC* 

.THlS_IS_A_SPEClFIc!:RESOURCe..L»BEL(STYPE),LABEL(tNSMEil 

RETURN! 

FOR* all  subnodes  OF  «RES0URCE.<*LA8EL (STYPE) ,#LABEL (SNAME) . 

$sched«unit,job_interval. start  <=  SAVAILABILITY.INTERVAI  •end 
) then  SASSIGN(NEXT)  = SAVAILABILITY! 

nrl^^cfto  ALi  SliBNOnES  OF  SNAME  USING  SSUBNAME! 

DO  FOR  ALL  SURNODES  OF  SSUBNAME. DESCRIPTOR  USING  SSUBDESCI 
IF  SSUBDESC. INITIAL  IDFNTIcAL  TO  SNljLL  THEN! 

ELSE  DO  FOR  ALL  SUBMODES  OF  SASSIGN  USING  SAVAlL! 

PICK  ONE  partition  OF  THE.  POOL  AT  THE  REQUIRED  TIME 

00  FOR  A|  L SURNODFS  OF  SAVaIL#DESCRIPTOR  USING 

SDESCrIP! 

SCONFlICT-,FLAG  * »YES*! 

IS  THE  REQUIRED  QUANTITY  GREATER  THAN  QUANTITY  AVAILABLE  IN  THIS 

partition?  if  not  check  other  descriptors  otherwi«?e  build 


DO 

IF 


/* 


♦ / 


/* 

/• 


/♦ 


*/ 

*/ 

*/ 


SDESCRIP. final. 

identical  to  SnULI 


CONFLICT  NODE  AND  FIND  NEXT  PARTITION 

IF  SSUBDfSC. INITIAL. QUANTITY  > 

quantity  & sdescrip.initial 

THEN! 

ELSE  00!  . ^ 

/*  are  other  descriptor  and  value  identical  ? 

graft  ssubdesc.initial. quantity  at 

sTEMpflQUAN!  „ . 

IF  ssubdesc.initial  subset  of  SDESCRIP. f,tnal 

8,  SDESCRIP. initial  IDENTICAL  TO  $NU|.  I 
THEN  DO! 

SC0NFLICT5«FLAG  a *N0»! 

graft  $temp_quan  at  ssubdesc.initial. 

QUANTITY! 

END! 

else  graft  STEMP^QUAN  at  SSUBDESC. 
INITIAL.QUANTITY! 

END! 

IF  $CONFi‘lCT:_FLAG  * *YES» 

THEN  00!  , . 

label (SPOOLED-RESOURCE-CONFLICTS (NEXT) ) s 
'lABFL(STYPE) ! 

SPOOLED  RES0URCE_C0NFLICTS(LAST) . 

SCHEO«UNIT«RES1oESCRIPTOR  « SSUBDESC. 
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INITIALI 

$P00LED_RES0URCE_C0NFLXCTS (LAST ) • 

SCHEnlUNlT«RES_DESCRIPTOR(NEXT)  ■ 
SSCHFD1.UNIT.J0B_INTERVALI 
SPOOLED  RESOURCE^CONFLICTS (LAST) . 

SCHEOULEDj?ESOURCE«DESCRlPTOR  « 
SOESCRIP.EINAU 

$POOLEOlRESOURCE_CONFLICTS(LAST) • 

SCHioULED-RESOURCE«DESCRlPTOR(NEXT)  s 

savail-intervali 

END I ^ - 

/•  PICK  NEXT  partition  OF  ASSIGNED  RESOURCES  FOR  THIS  ONE  REQUIRED  »/ 

END  I 

END I . ■ 

/*  PICK  NEXT  descriptors  FOR  THIS  REQUIRED  RESOURCE  */ 

END  I 

ENDI  • . 

/*  PICK  NEXT  REQUIRED  RESOURCES 
ENDI 
ENOI 

END!  /*  POOLEDlOESCRlPTOR'lCOMPATIBIILTY  ♦/ 
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2.4.15  DESCRIPT0R_PR0FILE 

2.4.15.1  Purpose  and  Scope 

This  module  is  used  to  update  the  set  of  descriptors  that 
apply  to  an  item-specific  resource,  i.e.,  an  individual,  identifi- 
able resource  that  would  correspond  to  the  first  subnode  level  of 

the  resource  -’type”  in  the  SRESOURCE  tree.  The  update  of  descrip- 
tors will. consist  of  an  assignment  or  set  of  assignments  that  de- 
fine initial  and  final  descriptors  for  each  assignment.  The 
original  set  of  descriptors  to  be  updated  and  their  corresponding 
values  will  be  supplied  by  the  calling  program.  This  cpuld  con- 
sist of  reference  to  the  resource  descriptors  in  the  $RES0URCE 
tree,  a derived  tree  that  has  been  maintaining  the  descriptors  of 
that  resource  as  a function  of  time,  or  a tree  built  by  the  call- 
ing program  with  specific  (possibly  artificial)  descriptors. 

Any  number  of  descriptive  parameters  may  have  been  used  in 
the  resource  assignments,  but  any  one  parameter  will  be  assumed 
to  contain  only  mutually  exclusive  values.  For  example.  If  the 
descriptive  parameter,  LOCATION  is  specified,  values  of  DENVER, 
DALLAS,  or  DETROIT  are  obviously  mutually  exclusive.  If,  however ^ 
the  location  were  specified  as  DENVER  and  a process  moved  the  re- 
source to  WAREHOUSE  3,  this  module  would  retain  only  the  location 
WAREHOUSE  3 whether  or  not  VJarehouse  3 was  located  in  Denver. 
2.4.15.2  Modules  Called 
None. 
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2.4.15.3  Module  Input 


Input  consists  of  the  item-specific  resource  to  be  considered, 
the  original  values  of  the  descriptors  to  be  updated  and  the  cor- 
responding time,  the  assignments  to  be  considered,  and  the  final 
time  that  assignments  are  to  be  considered.  The  resource  is  identified 
by  a pointer,  $RESOURCE_NAME , to  a second  level  subnode  of  the 
$rESOURCE  tree.  The  original  descriptors  and  their  values  are 
defined  under  the  INITIALJDESCRIPTOR  node  of  $RESOURCE-MAME . 

The  corresponding  time  is  defined  under  the  INITIALJTIME  node.  The 
assignments  to  be  considered  have  a format  corresponding  to  the  sub- 
node levels  of  the  ASSIGNMENT  node  in  $RESOURCE_NAME  as  illustrated 
in  the  sketch.  Any  nodes,  other  than  the  time  interval  and  descriptors 
(which  are  required),  will  be  retained  for  added  traceability.  The 
final  time  will  be  defined  by  a single  valued  tree  $MAX_TIME,  which 
will  represent  the  final  time  of  the  profile. 
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2.4.15.4  Module  Output 

The  output  consists  of  a "resource  state"  tree  (shown)  that 
lists  the  resource  descriptors  as  a function  of  time. 


$RESOURCE_STATE 


2.4.15.5  Functional  Block  Diagram 


2.4. 15-4 


2.4.15.6  Detailed  Design 

The  functional  block  diagram  may  be  used  as  the  flowchart  for 
this  module.  The  module  first  checks  to  determine  if  a 'pooled'  re- 
source has  inadvertently  been  transferred  through. the  parameter  list. 

If  this  happens,  an  error  message  is  written  and  control  is  returned 
to  the  calling  program.  Otherwise,  a tree,  $RESOURCE_STATE,  is  con- 
structed with  the  initial  descriptors  of  the  resource.  The  next 
assignment  of  the  resource  is  selected,  and  the  resource  descriptors 
are  compared  with  the  last  subnode  of  $RESOURCE__STATE.  If  any  of 
the  labels  or  the  values  change  a new  subnode  of  $RESOURCE__STATE  is 
added  with  the  new  label  and  value.  If  the  descriptors  have  not 
changed,  the  interval  in  $RESOURCE_STATE  is  extended  to  include  the 
current  interval.  When  all  assignments  have  been  considered,  or  the 
maximum  input  time  has  been  reached,  control  is  returned  to  the  call- 
ing program. 

2.4.15.7  Internal  Variable  and  Tree  Name  Definitions 

$ASSIGN  - Identifier  for  each  subnode  of  ASSIGNMENT 

$DUMMY  - Temporary  tree  made  up  of  descriptors  identified 

in  $ASSIGNMENT  which  are  not  in  $RESOURCE_STATE 
$LAST  - Pointer  at  the  descriptor  subnode  of  the  last 

subnode  of  $RESOURCE__STATE 

$NEW^DESCRIP  - Identifier  for  each  subnode  of  $DUMMY  when  new 
descriptors  are  recognized. 

$NEW__yALUE  - Identifier  for  each  subnode  of  $DUMMY  when  values 
of  descriptors  have  changed 

Identifier  for  each  subnode  of  initial  descrip- 

tors in  $ASSIGN 
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$SUBNAME  - Identifier  for  each  subnode  of  INITIAL^ 

DESCRIPTOR  node 

2.4.15.8  Modifications  to  Functional  Specification  and/or  Standard 
Data  Structures  Assumed 

Since  only  a single  resource  element  (second’ level  subnode  of 
$RESOURCE)  is  considered,  this  element  is  passed  through  the  param- 
eter list  as  $RESOURCE  NAME. 
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2.4.15.9  Commented  Code 


»/ 

*/ 


oescriptorIprofilE:  procedure {Sresource«.name 9$ assignment# 
$RES0URCE.STATE*$MAX«T1ME)  0PTJ0NS(EXTERNALM 
declare  $ASSlGN#SDUMMY*$LAST»i:NEWfr)ESCRlP»SNEW_VALUE»$PARAMETER, 

SSUBNAME  LOCaLI 
PRUNE  $RESOURCE_STaT£| 

IF  $RES0URCE«NAME. CLASS  = ‘POOLED* 

THEN  DOI  , . 

WRITE  »THIS*IS«A_P00LED‘^;RES0URCE»  » 

WRITE  LABEL(»RESOURCE.NaME)  I 
RETURNI 

/#  BUILD*rESOURCE  state  tree  with  initial  TIME  AND  CORRESPONDING 

DO  FOR^ALL^SUBNOOES  of  $RESOUrCE„NAME,INItIAL_OESCRIPTOR  using 

*SRES0URCE„STATE(FIPST) .DESCRIPTOR(NEXT)  = SSUBNAME? 

END!  , 

SRES0UftCE.STATE(FlRST).DESCRlpT0R,0UANTlTYall 

SRESOURCE.STATE (FIRST). interval. START  =:  ^RESOURCE  NAME. INITIAL  TlH^  . 
SRESOURCE^STATE (FIRST) , INTERVAL. END  * fRESOURCE-STATE (FIRST) .INTERVAL. 

START?"  < i 

/*  LOCATE  NEXT  ASSIGNMENT  TO  BE  CONSIDERED  *' 

IF  SASSIGNMENT (FIRST)  IDENTICAL  TO  SNULL 
then  DOI 

PRUNE  SASSIGNMENT I 

SRESOURCE_STaTE(FIRST) .INTERVAL. END  = SMAX..TIMEI 
RETURNI 
ENDI 

DO  FOR  ALL  SUBNOOES  OF  SASSIGNMENT  USING  SASSIGNI 

PRUNE  SDUMMYI  ^ „ ■ 

/#  has  maximum  allowed  time  been  reached?  * 

IF  SASSIGN. INTERVAL. start  >#  SMAX^TIME 
THEN  DOI 

SRESOURCEISTaTE(LAST) .intfrval*end  = $max_timei 
PRUNE  SRES0URCE_STATF (LAST) . JOB^ID? 

RETURN! 

ELSE*^SRES0URCE_STATE (LAST) .INTERVAL.END  = SASSIGN. INTERVAL. EnDI 
HAVE  ALL  OF  THESE  DESCRIPTIVE  PARAMETERS  BEEN  INCLUDED  IN  */ 

PREVIOUS  interval? 

IF  SASSIGN. OESCrIPTOR(FIRST) .INITIAL  -^SUBSET  OF 
$resource_sTate (LAST) .Descriptor 

BUILD  NEW  NODE  ON  OUTPUT  TREE  TO  REFLECT  NEW  VALUES  »/ 

^DO^FOR  all  SUBNOOES  OF  SASSIGN. DESCRIPTOR (FIRST) . INITIAL 

USING  SPARAMETeRI  , ^ - 

IF  SPARAMETER  *.ELEMEnT  OF  SRESOURCE.STATE(LAST) .DESCRIPTOR 
THEN  SDUMMY(NExT)  s SPARAMETERI 

DO^FOR  all  SUBNODES  oF  SDUMMY  USING  SNEW^DESCRIP I 

IF  SRpSOURCE.STATF (LAST) .descriptor. #LABEL(5NEW.DESCRIP) 


/♦ 

/* 


/• 
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IDENTICAL  To  SNULL  THENI  ^ 

ELSE  WRITE  *THe-VALUEl0F«THIS.0ESCRlPT0R.CHAN6ESlATiTHFB 
START«OF«THE.ASSi«NMENT**LABEL(SNEW;.DESCRlP)  *$NEWJ)ESCRIPl 

sresource.statf(last) . descriptor. #LABEL($NEW.0ESCRIP)  ■ 
$NEWJ)ESCRIP| 

endi 

END! 

elsei 

/*  DO  any  of  the  values  CHANGE  for  THESE  PARAMETERS?  . •/ 

IF  (SASSIGN.OESCRIPTOR(FIRST) .Final  identical  to  SNULL  I SAGgIGn. 
DESCRIPTOR (FIRST) .final  SUBSET  OF  SASSIGN. DESCRIPTOR (FIRST) 

•initial) 

/*  ADD  INTERVAL  To  LAST  NODE  OF  OUTPUT  TREE  */ 

THEN  IF  SASSIGN. interval. PND  >*  SMAX.TIME 
THEN  DOI 

SRESOURCE^STATF(LAST) .JOB.IO  e SASSIGN. JOB.IDI 
RETURNI 

enBi 

elsei 

ELSE  IF  SASSIGN. Interval. END  >«  smax.time 
then  DOI 

DO  FOR  all  SUBnOOES  OF  SASsIGN. DESCRIPTOR (FIRST) .FINAL 
USING  SPaRAMETERI  . , 

IF  SPaRAMETER  -^Ei’EMENT  OF  SRESOURCE.STATE (LAST)  •DESCRIPTOR 
THEN  SDUMMY(NEXT)  * SPARAMETERI 
ENDI 

SRESOURCE.STATf(LAST) .JOB.IO  * SASSIGN. JOB^IDI 
DEFINE  SLAST  AS  SRESOURCE.STATE (LAST) .DESCRIPTOR! 
SRESOURCE^STATf (NEXT) .DESCRIPTOR  ■ SLASTI 
SRESOURCE^STATE (LAST) .interval. START  » SASSIGN. InTErVAi  . 
ENDI 

SRESOURCE^STATe (LAST) .interval. END  » SASSIGN. INTERVAL. 
ENDI 

DO  FOR  ALL  SUBnODES  OF  SDUMMY  USING  SNEW.VALUEI 

SRESOURCE.STATE (LAST) . DESCRIPTOR. #LABEL (SNEW^VALuE) 

« snew«valuei 

ENDI 

RETURNI 

enBi 

else  DOI  . 

/•  BUILD  NEW  NODE  ON  OUTPUT  TREE  TO  REFLECT  NEW  DESCRIPTORS  */ 

DO  FOR  all  SUBnODES  OF  SASSIGN. DESCRIPTOR (FIRST ) .FINAL 
USING  SPaRAMETERI  _ / 

IF  SPaRAMETER  -ELEMENT  OF  SRE$OURCE.STATE (LAST) .DESCRIPTOR 
THEN  SDUMMY (NEXT)  » SPARAMETERI 
END! 

SRES0URCE_STATE(LAST) .JOB^ID  « SASSIGN. JOB^IOI 
define  SLAST  AS  SRESOURCE.STaTE (LaST) .DESCRIPTOR! 
SRESOURCE^STATF (NEXT) .DESCRIPTOR  ■ SLASTl 

SRESOURCE^STATE (LAST) .interval. start  a SASSIGN. iNTEpVAl  . 
ENDI 
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DO  FOR  ALL  SUBnODES  OF  SDUMMY  USING  $NEW.VALUE» 

jresource.statE(last) . descriptor. #LABEL($NEW_VALUE) 

« SNEw.VALUEI 

ENDl 

END! 

HAVE  ALL  assignments  BEEN  CONSIDERED?  */ 

end; 

end;  /»  descriptor_profilf  */ 
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2,4.16  UPDATE  RESOURCE 


2.4.16  UPDATE  RESOURCE 


2.4.16  UPDATE_RESOURCE 

2.4.16.1  Purpose  and  Scope 

This  module  will  update  information  in  the  data  tree  $RES0URCE 
for  each  resource  assigned  to  a specific  J0B_rD  in  the  structure 
$SCHEDULE,  It  provides  a standard  method  of  reflecting  in 
$RES0URCE,  the  results  of  a scheduling  decision.  It  creates  a 
data  structure  $NEXTUMIT  that  contains  element(s)  to  be  added  to 
the  chronologically  ordered  assignments  of  a specific  $RES0URCE. 
(TYPE) . (NAME)  by  calling  the  module  WRITE_ASSIGNMENT . 

2.4.16.2  Modules  Called 

WRITE_ASSIGNMENT 

2.4.16.3  Module  Input 

Inputs  consist  of  the  standard  data  structures  $SCHEDULE  and 
SRESOURCE,  that  are  shown  in  standard  form  on  the  following  pages. 
The  minimum  relevant  portions  of  the  required  input  structures 
are  shown  on  subsequent  pages. 

2.4.16.4  Module  Output 

During  execution'  the  module  creates  the  data  structure 
$NEXTUNIT.  (See  the  following  illustrations)  After  execution, 
the  SRESOURCE  tree  will  reflect  the  changes  in  assignments  that 
result  from  the  scheduling  of  all  jobs  in  $SCHEDULE. 
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Note;  Minimum  (i.e.,  relevant)  portion  of  required  input  Standard  Data  Structures 
is  shown.  In  all  trees,  any  additional  structure  will  be  preserved. 


$SCHEDULE 


(TYPE) 

(NAME) 


Minimum  Required  Input  Structures  from  Standard  Data  Structures 
for  Module:  UPDATE JESOURCE 
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2.4.16.5  Functional  Block  Diagram 


2.4.16-4 


2.4.16.6  Typical  Applications 


The  module  would  be  used  during  or  after  the  construction  of 
a schedule  to  record  the  changes  to  the  resource  assignments  re- 
sulting from  temporary  or  permanent  decision  to  schedule  specific 
jobs. 
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4.16.7  DETAILED  DESIGN 

The  functional  block  diagram  provides  the  flow  chart  for  this 
module.  The  module  loops  on  job,  resource  type,  and  resource  name  as 
specified  by  the  input  data  structure  $SCHEDULE.  For  each  specified 
resource  element  the  data  structure  $NEXTUNIT  is  constructed.  If  this 
resource  element  is  not  contained  within  $RESOURCE,  the  normal  initial 
profile  is  constructed  in  $RESOURCE.  For  each  specified  resource 
element,  the  module  WRITE_ASSIGNMENT  is  called  to  add  the  element  to 
the  chronologically  ordered  assignments  of  $RESOURCE. 


h.16.8  INTERNAL  VARIABLE  AM)  TREE  ttAMES 

The  internal  variables  used  in  this  module  are  listed  below,  with 

definitions . 

qUAN  - Summation  of  quantities  of  partitions  of  a pooled  resource. 

$TYPE  - A single  node  tree  containing  only  the  label  of  resource 
type  provided  in  input  $SCHEDULE'. 

$NAME  - A single  node  tree  containing  only  the  resource  name 
provided  by  the  input  $SCHEDULE. 

$NEXTUral  - A data  structure  derived  from  $RESOmCE,  but  containing 

only  the  assignment  subnode  of  a single  resource  element. 
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2.4.16.9  COMMENTED  CODE 


U^DATE«,RES0URCE i procedure ($ScHEDULE*SRESOURCE)  options (EXTERNAL) I 
OKCLARE  I # J*K*Lf M»OUANtSNAME*«TYPE  LOCALI 
DECLARE  SNEXTUNIT  LOCALI 


/• 

/* 


/* 


CONSIDER  NEXT  JOB. 

DO  I * 1 TO  number (SSCHEDUlE) I 


CONSIDER  NEXT  RESOURCE  TYPE. 

DO  J * I TO  nUMBER(SSCHePULE( I) .RESOURCES) I 
CONSIDER  NEXT  RESOURCE  NAME. 

DO  K ■ 1 TO  NUMBER($SCHEDULEa>  .RESOURCESCJ)  ) I 
STYPE  = LABEL(SSCHEOuLE(I) .RESOURCES(J)) I 
SNAME  a LABEUSSCHEDuLE  (I). RESOURCES  ( J)  (K))  I 
WRITE  initial  time*  DESCRIPTOR  IF. NEW  RESOURCE. 

IF  sresource.#($type> .#(sname)  identical  to  SNULL 


*/ 

• / 
« 


SRESOURCE*# (STyPE) •# (SNAME) • INITIAL„TIME  * SSCHEOULF < I ) . 

RESOURCES(Ji (K) (1) .interval. EnDI 
DO  L * 1 TO  number (^SCHEDULE (I) .RESOURCES (J) (K) ) I 
5RES0URCE.#(STyPE)  .«(1?NAME)  .INITIAL«PR0FILF.N0RMAL(I  ) 

* JSCHEDULFd)  .RESOURCES  (J)  (K)  (L)  .INTERVAL* 


/* 


/# 


/» 


QUAN  a 0* 

DO  M a 1 TO  NUMBER(*SCHE0ULE (I) .RESOURCES (J)  (K) (I  ) • 
DESCRIPTORS); 

qUAN  a QUAN  ♦ SSCHEDULE < I ). RESOURCES ( J )( K )( L ) . 

descriptors(m) .final. quantity? 

SRESOURCE.#  (STyPE)  .«  (SNAME)  . INITI  AL..PROFILE. NORMAL  (i  ) 
.quantity  a OUANI 


END! 

ENDI 

create  snextunit  for  current  RFSOURCE/JOB. 

label  (SNEXTUNIT.RESoURCES(J) ) = STYPE* 

LABEL  (SNEXTUNIT. RESoURCES(J) (K) ) a SNAME* 

DO  L * 1 TO  NUMBEP(«SCHEDULE(I) .RESOURCES(J) (K) ) I 

*NEXTUNlT.flESOURCFS(J) (K) (L)  = SSCHEOULE ( I ) .RESOURCES 

SNEXTUnIt!rESOURCfS(J) (K) (L) .JOB_ID  = LABEL ( SSCHEDUlE 

IF  SSrHEDULE(I) .PROBLEmInamE  -IDENTICAL  TO  SNULL  THEN 
snextunit. RESOURCES(J) (K> (L) .PROHLEM^NAME  a 
SSCHEOULE ( 1 ) .prorlem.namE I 
IF  SSCHEOuLe (I ) .OpSEQ  -IDENTICAL  TO  SNULL  THEN 
SNEXTUNIT. RESOuRCES(J) (K) (L) .OPSEQ  = 
sschedule ( I > .OpSEQI 

snextunit, RESOURCfS(J) (K) (L) .PROCESS  a 


ssOHEDULEd) .Process*  ^ 

SASSIGnMENT.UNIT  s snextunit, resources (J)  (K)  (L)  I 
o A I I'  WQTTE  ASSTGNMENT  ti  — 

call  WrITF*‘ASS16NmENT (f ASSI6NmENT_UNIT »SRES0URCE,W (STYpE) 
#(SnAMeT.  ASSIGNMENT) * 

end  LOoP-L*  end* 

HAVE  ALL  resource  NAMES  Op  THIS  TYpE  BEEN  CONSIDERED? 


*/ 
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END.LOOP-K*  end  I 

/•  HAVE  ALL  resource  TYPES  OF  THIS  JOB  BEEN  CONSIDERED? 
ENO.LOOP-.Jl  END  I 

/•  HAVE  ALL  JOBS  BEEN  CONSIDERED? 

END.LOOP.I*  END I 

return I 

END  I /*  UPOATE.RESOURCE  ♦/ 


li 
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2,4.17  WRITE  ASSIGNMEISrr 


2.4.17  WRITE_ASSIGNMENT 

This  module  will  add  an  element  to  the  chronologically 
ordered  assignments  of  the  $ASSIGN  tree  for  a specified  resource 
name  and  type.  Basis  for  the  order  is  the  resource  interval  start 
time.  If  start  times  are  equal,  the  assignment  with  an  earlier 
end  time  is  listed  first.  If  start  and  end  times  are  equal,  no 
distinction  is  made  in  the  order. 

The  specific  data  written  for  an  assignment  can  vary  with  the 
calling  module.  That  is,  dummy  assignments  may  be  made  as  a 
means  of  constraining  resources  in  which  case  processes,  prob- 
lem names,  etc  may  be  meaningless.  However,  selected  resources 
for  a given  problem  may  contain  many  parameters  and  descriptors 
that  define  the  usage  and  provide  traceability  for  later  re- 
trieval . 

2.4.17.2  Modules  Called 

None 

2.4.17.3  Module  Input 

Inputs  to  this  module  consist  of  $ASSIGNMENT_UNIT,  the  as- 
signment node  of  $NEXTUNIT  for  which  the  assignment  is  to  be 
written,  and  identif icaiton  of  the  $RES0URCE  subnode  where  the 
assignment  is  made.  In  the  standard  case,  the  entire  substruc- 
ture of  one  of  the  third-level  subnodes  of  $NEXTUNIT . RESOURCE 
becomes  the  substructure  for  one  element  of  the  standard  data 
structure  subnode  $RES0URCE . (TYPE) . (NAME) .ASSIGNMENT  that  cor- 
responds to  the  subnode  identified  by  $ASSIGN. 
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MINIMUM  REQUIRED  INPUT  STRUCTURES  FROM  STANDARD  DATA  STRUCTURES 
FOR  MODULE:  WRITE_ASSIGNMENT 


Note: 


Minimum  (i.e.,  relevant)  portion  of  required  input 
standard  Data  Structures  is  shown.  In  all  trees,  any 
additional  structure  will  be  preserved. 


$ASSIGN  $ASSIGNMENTJJNIT 


INPUT  DATA  STRUCTURE 
$ASSIGNMENT_UNIT 
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2.4.17.4  Module  Output 


This  module  will  modify  $ASSIGN  to  include  an  additional 
assignment  element  for  the  specified  resource  and  corresponding 
time  interval . 

2.4^17.5  Functional  Block  Diagram 


^ Enter  ^ 


Search  for  first  assignment 
with  an  equal  start  time  and 
later  end  time  or  later  start 
time. 


I 


Insert  $ASSIGNMENTJJNIT  in 
Assignment  tree 


2.4.17.6  Typical  Applications 

This  module  is  used  to  create  a new  assignment  interval  for 
a specific  resource  that  has  been  selected  for  a given  process. 
The  selected  interval  may  be  a tentative  selection  used  during 
the  solution  of  a given  problem  or  the  "final"  assignments  de- 
cided upon.  Nevertheless,  an  assignment  for  a specific  resource 
must  be  made  to  indicate  its  "nonavailability"  during  the  assign- 
ment interval. 
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2. h. 11.1  Implementation  Considerations 

An  example  flow  diagram  of  this  module  is  shown  in  the  sketch. 
EXAMPLE  FLOW  DIAGRAM  OF  WRITE  ASSIGNMENT 


WRITE  ASSIGNMENT 


2. A. 17. 9 


DEIAILED  DESIGN 

As  this  module  was  originally  conceived,  proper  placement  of  the 
current  $ASSIGNMENT_UNIT  was  determined  by  comparing  it  with  the  in- 
tervals in  $ASSIGN  in  a chronological  manner.  However,  it  is  expected 
that  the  usual  placement  will  be  as  the  last  interval,  so  the  ordering 
of  comparisons  was  reversed.  This  is  illustrated  in  the  flowchart 
sketched  below.  ' 

Since  placing  the  interval  as  the  first  one  in  $ASSIGN  is  also 
expected  to  occur  frequently, a check  for  this  condition  is  made  first. 
Then  comparisons  of  the  interval  of  $ASSIGNMENT_UNIT  with  each  interval 
of  $ASSIGN  are  made  starting  with  the  last  and  incrementing  towards  the 
first.  If  the  start  time  of  $ASSIGNMENT_UNIT  is  greater  than  that  of 
the  Ith  interval  of  $ASSIGN,  or  if  the  start  times  are  equal  and  the 
end  time  of  $ASSIGNMENT_UNIT  is  greater  than  that  of  the  Ith  interval; 
$ASSIGNMENT_UNIT  is  inserted  after  the  Ith  interval. If  the  start  times 
are  equal  and  the  end  time  of  $ASSIGNMENT_UNIT  is  less  than  that  of 
the  Ith. interval,  $ASSIGNMENT_UNIT  is  inserted  before  the  Ith  interval 
of  $ASSIGN. 


2.4.17-6 
Rev  B 


2.4.17.10  COMMENTED  CODE 
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WRITE^SSIGNMENTI  procedure  (S'ASSlGNMENT.UNITtSASSIGN) 

OPTIONS(EXTERNAL) I 
I « 01 

/♦  IS  START  time  of  SASSiGNMpNT.UNIT  LESS  THAN  THAT  OF  i/ 

/*  FIRST  INTERVAL  IN  fASSiGN? 

IF  SASSIGNMENT.UHIT. interval. START  < SASSIGN ( I ) , INTERVAL.START 
then  go  to  InSERT.AI 

/♦  set  I s number  of  subnodes  of  SASSIGN  ;/ 

do  I = NUMBER($aSSIGN)  to  I BY  -u 
/*  IS  start  time  of  SASSIGNMeNT.UNIT  less  than 
/*  THE  I»TH  interval  START  TjME? 

IF  SaSSIGNMENT.UNIT. interval. START  < SASSIGN ( I ). INTERVAL. START 
Then  go  to  end^loopi 
/*  are  START  Times  equal? 

IF  SASSIGNMENT.UNIT. interval. START  SASSIGNU ). INTERVAL. START 

then  go  To  insert.ai 

/*  IS  END  TIME  OF  SASSIGNMENt.UNIT  LATER  THAN  */ 

/*  THE  i»th  Interval  end  time?  ♦/ 

IF  SaSSIGNMENT-UNIT. interval. END  >a  SASSIGN ( I) • INTERVAL. END 
then  go  To  insert^a; 

ELSE  GO  To  END^LOOP  I 

/♦  I = I - 1 ;/ 

end^loop:  end  I 

/*  insert  sassignmentIunit  After  the  i»th  surnode  of  sassign  */ 

INSERT^a:  insert  SaSSIGNMEmTIunIT  before  SASSiGNd*!) 

RETURNI 

/*  insert  sassignmentIunit  before  the  i*th  subnode  of  sassign  #/ 

END  I /#  WRITEIaSSTGNMENT  »/ 
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2,4.18  UNSCHEDUtE 


2.4.18  UNSCHEDULE 


2.4.18  UNSCHEDULE 


2.4.18.1  Purpose  and  Scope 

This  module  deletes  assignments  from  the  $RES0URCE  tree  for 
a given  resource  or  collection  of  resources.  The  deletion  may  be 
for  a single  assignment  or  a collection  based  on  particular  proc- 
esses and/or  jobs  depending  on  the  contents  of  the  tree 
$UNSCHEDULE. 

2.4.18.2  Modules  Called 
None 

2.4.18.3  Module  Input 

Inputs  to  this  module  by  the  calling  argument  will  be 
$RES0URCE  and  $UNSCHEDULE  as  shown. 
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MINIMUM  REQUIRED  INPUT  STRUCTURES  FROM  STANDARD  DATA  STRUCTURES 
FOR  MODULE:  UNSCHEDULE 


INPUT  DATA  STRUCTURE 


$UNSCHEDULE 
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2.4.18.6  Typical  Appilcanions 


This  niodule  will  be  used  to  negate  assignments  that  may  have 
been  tried  in  the  problem  solution  sequence  or  to  update  $RES0URCE 
if  previous  problem  solutions  were  to  be  altered. 
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This  module  will  be  used  to  negate  assignments  that  may  have 
been  tried  in  the  problem  solution  sequence  or  to  update  $RESOURCE 
if  previous  problem  solutions,  were  to  be  altered, 

2.4.18.7  Detailed  Design 

The  functional  block  diagram  for  this  module  is  sufficiently 
detailed  for  use  as  a program  flowchart.  The  module  loops  on  job, 
resource  type,  and  resource  name  as  specified  by  the  input  tree 
$UNSCHEDULE,  For  each  specified  resource  element,  the  assignment 
is  located  in  the  $RESOURCE  tree  and  is  pruned.  If  the  resource  to 
be  unscheduled  is  not  found  in  $RESOURCE  a message  to  this  effect 
and  the  resource  description  and  interval  are  output. 

2.4.18.8  Internal  Variable  Definitions 

$ASSIGN  - Identifier  for  each  subnode  of  ASSIGNMENT 

node 

$DESCRIP  - Identifier  for  each  subnode  of  $NAME 

$NAME  - Identifier  for  each  subnode  of  $TYPE 

$TYPE  - Identifier  for  each  subnode  of  RESOURCE 

node 

$UNSCHED  JOB  - Identifier  for  each  subnode  of  $UNSCHEDULE, 
this  is  the  job  to  be  unscheduled 
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2.4.18.9  COMMENTED  CODE 


UNSCHEOULE:  PROCEDURE (SUNSCHEdULE*SRESOURCE>  OPTIONS (EXTERNAL) » 

OlCLARE  $UNSCHE0lJ0B#STYPEt$NAME#SnESCRlP;SASSlGN  LOCAL! 

/•  CONSIDER  next  JOB, 

DO  FOR  ALL  SUBNODES  OF  SUNSCHFDULE  USING  SUNSCHED.JOB ! 

/•  CONSIDER  next  RESOURCE  TYpE, 

DO  FOR  ALL  SUBNODES  OF  SUNSCHEO«JOB. RESOURCE  USING  STYPE! 

/*  CONSIDER  NEXT  RESOURCE  NAmE, 

DO  FOR  ALL  SUBNODES  OF  *TYPE  USING  SNAMEI 
/♦  LOCATE  assignments  TO  BE  DELETED  BASED 
/*  ON  INTERVALS  AnD  DESCRIPTIONS  IN  SUNSCHEDULE# 

DO  FOR  all  SUBNOOES  oF  SNAME  uSInG  SDESCRIP! 

DO  FOR  ALL  SUBNODFS  OF  IRESOURCE*# (LABEL < STYPE) ) . 
#(LABEL(SNApEj ) .ASSIGNMENT  USING  SASSIGNI 

/*  prune  assignment  elements. 

IF  SDESCRIP. INTERVAL  IDENTICAL  TO  SASSIGN. INTERVAL 
THEN  IF  SDESCRiP. descriptor  IDENTICAL  TO  SaSSIGN. 
DESCRIPTOR  THEN  PRUNE  SASSIGNI 

END! 

END! 

/*  HAVE  ALL  resource  NAMES  OF  THIS  TYPE  BEEN  CONSIDERED?  #/ 

END*  . 

/*  HAVE  ALL  RESOURCE  TYPES  OF  THIS  JOB  BEEN  CONSIDERED?  */ 

END! 

/*  HAVE  ALL  JOBS  BEEN  CONSIDERED? 

END! 

RETURN! 

END!  /<»  UNScHEOULE  */ 
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2.4.19  COMPATIBILITY_SET^ 
GENERATOR 
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2.4.19  COMPATIBILITY_SET_GENERATOR 

1 

2.4.19.1  Purpose  and  Scope 

The  purpose  of  this  module  is  to  enumerate  all  compatible 
subsets  of  a given  set  when  properties  determining  compatibility 
have  the  following  frequently  occurring  structure. 

1)  Each  element  of  the  set  has  a common  set  of  quantitative 
properties . 

2)  Each  subset  of  the  set  has  the  same  set  of  properties  defined 

I 

by  certain  composition  rules  on  the  corresponding  properties 
of  its  elements. 

3)  For  a subset  to  be  compatible,  each  of  its  properties  is  con- 
strained to  be  either  less  than  or  greater  than  some  limiting 
value. 

4)  The  composition  rules  are  such  that  the  constraint  on  any 
properties  of  any  subset  can  only  be  tightened  by  adding 
another  element  to  that  subset. 

.For  Such  sets  and  rules  then,  the  compatibility  set  generator 
enumerates  all  of  the  ordered  compatible  subsets  where  the  order 
is  that  of  the  input  set.  The  enumeration  is  done  in  the  .lexico- 
graphic order  based  upon  the  original  input  ordering.  By  making 
use  of  the.  fact  that  under  the  above  property  of  composition  rules 
any  subset  of  a compatible  subset  must  in  turn  be  compatible,  a 
recursive  enumeration  scheme  can  be  devised  that  is  far  more 
efficient  than  examination  of  all  ordered  subsets  or  even  the 
back-tracking  procedure  used  by  Walker. 
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The  algorithm  should  be  able  to  handle  sets  of  cardinality  up 
to  100  with  compatibility  rules  generating  up  to  10,000  compatible 
subsets  of  average  cardinality  3.  Execution  time  should  be  held 
to  a minimum. 

2.4.19.2  Algorithm  Description 

l^Jhen  it  is  knoxm  that  any  subset  of  a compatible  subset  is  in 
turn  compatible,  the  entire  collection  of  ordered  compatible 
subsets  can  be  efficiently  enumeruted  recursively.  Let^^  denote 
a sequential  set  of  indices  denoting  the  respective  elements  of 
some  set  whose  compatible  subsets  are  to  be  generated.  Let 
denote  an  arbitrary  ordered  compatibility  subset  of of  cardin- 
ality k Let  E denote  the  set  of  elements  from  5^ which  can  be 
^ n 

augmented  to  to  form  a new  ordered  compatibility  set  of 
cardinality  k+1 . Symbolically 

[11  Cp  = U {e}} 

is  a compatible  subset  and  e is  greater  than  any  element  in 
Next,  let  P.  be  the  set  of  elements  from  which  taken  after  £ , 
constitute  an  ordered  compatible  subset;  that  is 
1^2]  P = {p'  : {•'  ,pf  is  a compatible  subset  and  p > } 

Consider  any  element  e in  E^.  Ifhat  elements  i.  frornoi^are  eligi- 
ble for  addition  to  the  ordered  set  U {e}  of  cardinality 

k+1  to  form  the  ordered  set  = 0^1)  { 1 of  cardinality  k+2? 
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Clearly,  ••  must  be  both  greater  than  e and  compatible  x^?ith  it; 


that  is  f is  an  element  of  P • Further,  since  any  subset  of  a 

e 

compatible  subset  must  be  compatible  U must  be  an  ordered 

compatible  subset  for  any  1 greater  than  e.  Thus,  to  determine 

all  the  ordered  compatible  subsets  of  cardinality  k+2  that  have 

the  ordered  compatible  subset  of  cardinality  k+1  as  a subset, 

it  is  only  necessary  to  examine  order  subsets  of  the  form 

C U {i!.}  where  is  an  element  of  the  ordered  set 
P 

B = p n E 1 
ne  e ' ' n 


The  notation  S]  denotes  the  ordered  subset  of  the  ordered  set  S 
s 

consisting  of  those  elements  that  are  strictly  greater  than  s. 

By  building  an  enumeration  tree  in  which  each  node  corresponds 
to  an  ordered  compatible  subset  all  such, subsets  can  be  constructed. 
The  decendants  of  each  node  are  precisely  those  derived  from  it  by 
the  addition  of  one  element.  Each  set  of  nodes  in  the  tree  repre- 
senting ordered  compatible  subsets  of  the  same  cardinality  con- 
stitutes a level.  Thus,  the  tree  can  be  built  recursively  level 
by  level. 

The  efficiency  ol  this  recursive  enumeration  over  the  straight- 
forward process  of  examining  all  2^  subsets  (L  is  the  cardinality 
of^)  can  be  considered  if  the  constraints  are  reasonably  tight. 

In  the  extreme  case  of  no  compatible  subsets,  the  recursive  enum— 
eration  xvould  terminate  after  the  examination  of  only  L subsets 
while  the  complete  enumeration  process  will  still  try  all  2 
subsets . 
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2.4.19.3  Module  Input 

1)  Set(sC  of  sequential  indices  denoting  set  elements; 

2)  Procedure  for  determining  whether  or  not  a given  subset  is 
compatible . 


2.4.19.4  Module  Output 

1)  Number  M of  ordered  compatible  subsets; 

2)  Complete  and  nonredundant  lexicographic  list  of  ordered 
compatible  subsets, 

3)  Cardinality  K of  largest  compatible  subset; 


I m=l  ’ 


4) 


Complete  set  of  starting  indices  for  classes  of  compatible 


subsets  with  the  same  cardinality, 
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2.4.19.5  Functional  Block  Diagram 
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NOTES  ON  FUNCTIONAL  BLOCKS 

1)  Initial  node  definition: 

a)  The  first  node  in  the  tree  corresponds  to  the  null  subset 
(trivial  node) . 

b)  Its  descendants  correspond  to  the  compatible  singleton 
subsets  of 

2)  Branching  rule: 

Let  the  compatible  subset  corresponding  to  the  current  node 

be  C , and  the  subset  corresponding  to  its  antecendent  be  C^. 
p’ 

Suppose  {el  is  augmented  to  C^  to  form  C^;  that  is 

C = C Ufe}. 

P n 

Consider  the  set 

B = p n E 

ne  e n 

J ® 

as  previously  defined.  For  each  S,  element  of  B^^  such  that 

C = C U {e}  is  compatible,  create  a new  descendant  node  for 
m p 

the  current  node. 

3)  Current-node  selection  rule: 

Once  branching  is  completed  at  a node,  the  next  node  selected 
is  that  corresponding  to  the  next  compatible  subset  of  the 
same  cardinality  (the  next  node  at  the  same  level  in  the  tree) . 
If  no  such  node  exists,  that  node  corresponding  to  the  first 
compatibility  set  of  one  greater  cardinality  is  selected;  i.e., 
the  first  node  in  the  next  level  of  the  tree  is  chosen. 


2.4.19-6 


2.4.19.6  Typical  Applications 

Givan  a set  of  payloads,  determine  all  subsets  whose  elements 
can  fly  together  on  a single  flight.  Representative  con- 
straints would  be 

1)  Cargo  composite  weight  can  not  exceed  Shuttle  capability; 

2)  Cargo  composite  launch  window  must  be  at  least  2 days  wide; 

3)  Cargo  composite  volume  cannot  exceed  that  of  Shuttle  cargo  bay. 

2.4.19.7  Implementation  Recommendations 

Not  all  of  the  enumeration  tree  or  the  corresponding  compati- 
ble subsets  need  be  maintained  in  high-speed  memory. 


2.4.19.8  References 

Walker,  R.  J.,  "An  Enumerative  Technique  for  a Class  of  Combina- 
torial Problems,"  Chapter  7 in  R.  Bellman  and  M.  Hall,  Jr . (editors) , 
ComhinatoHal  Analysis,  Proceedings  of  Symposivm  on  Applted  Mathe- 
matics, Volume  10,  Page  91-94,  American  Mathematical  Society, 
Providence,  Rhode  Island,  1960. 
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2.4.19.9  Detailed  Design 


This  module  builds  an  enumeration  tree  of  compatible  subsets  of 
the  original  input  set  of  elements  subject  to  criteria  input  by  the  user 
The  allowable  criteria  are:  1)  sum  of  descriptor  values  must  be  less 
than  or  equal  to  a maximum;  2)  descriptor  values  must  be  less  than  or 
equal  to  a maximum;  3)  descriptor  values  must  be  greater  than  or  equal 
to  a minimum;  and  4)  descriptor  values  must  be  equal  to  a value.  The 
module  steps  through  the  input  $SET  testing  each  element  against  the 
criteria  and  if  acceptable,  then  building  compatible  subsets  of  these 
elements.  Then  subsets  are  generated  of  greater  cardinality  and  tested 
for  compatibility.  The  output  contains  the  indices  of  the  elements  of 
$SET  which  are  elements  of  compatible  subsets.  The  indices  are 
output  as  labels  of  the  nodes  of  $COMPATIBLE_SUBSET_TREE . Each 
branch  contains  the  indices  of  a compatible  subset. 
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2,4.19,10  Internal  Variable  and  Tree  Name  Definitions 


$compatible_subject_tree 


INDEX  OF  SET  ELEMENT 


$SET 


$SET_ELEMENT 

COMPAT  IBLE_E  LEMENT_F  LAG 

$ INDICE  S_OF_SUBSET_ 
EIEMENTS 

COMPATIBLE_SUBJECT_FLAG 

$FAMILY_HEAD 

INDEX_OF_CHILD 

$CHILD 

INDEX  FIRST  POSSIBLE 


“ output,  containing  the  compatible 
subsets 

tracks,  index  of  $SET_ELEMENT  within 
$SET 

- input,  describes  the  set  of  elements 
with  descriptors  which  are  to  be 
examined  for  compatibility 

points  at  subnodes  of  $SET 

- if  equal  to  0,  elements  are  not  compatible; 
if  equal  to  1,  they  are  compatible 
contains  a set  of  indices  from  INDEX_0F_ 
SET_ELEMENT 

- if  equal  to  0,  the  sum  has  exceeded  upper 
limit 

- equivalent  to  $COMPATIBLE_SUBJECT_TREE 
the  index  of  $ CHILD 

- points  at  subnodes  of  $FAMILY_HEAD 

- equal  to  the  index  of  $CHILD  plus  1 


grandchild 

INDEX_OF_POSSIBLE_GRANDCHILD  - temporary  counter 

INDEX  FIRST  " the  index  of  the  $CHILD  of  $FAMILY_HEAD 

COMI*ATIBLE_DOUBLET_FLAG  - the  index  of  the  possible  grandchild  of 

$FAMILY._HEAD 

DOUBLET_PREVIOUSLY_CHECKED__  “ equals  0 if  doublet  has  been  previously 

checked 
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$UNEXAMINED_FAMILY_HEADS 

$ IN  DICE  S_OF_POS  S IB  LE_NEW_ 
SUBJECT 

$FAMILY_HEAD_INDEX 

MEMBER_INDEX 

$COMPATIBILITY_CRITERIA 

$EQUALITY_CONSTRAINT 

$ INDICE  S_OF_POS  S IB  LE_NEW_ 

SUBJECT 

INDEX_SECOND 

DESCRIPTOR_SUM 

$ INDEX_OF_SUB  JECT_E  LEMENT 

$ SUM_UPPER_LIMIT 


INDEK 


$LOWER_LIMIT 


$UPPER_UMIT 
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contains  the  indices  of  $CHILD  as  potential 
$FAMILY_HEADs . 

contains  indices  of  $FAMILY_HEAD 

defines  the  index  of  the  node  the  current 
one  came  from 

value  of  $FAMILY__HEAD_INDEX  subnode 
input  describing  the  criteria  on  which 
$SET  are  to  be  evaluated 
points  to  subnodes  of  $COMPATIBILITY_ 

CRITERIA 

contains  the  indices  of  possible  family 
heads 

equal  to  the  value  given  by  $FAMILY_HEAD 
sub  INDEX_OF_POSSIBLE_GRANDCHILD 
variable  used  to  sum  up  the  descriptor 
values 

points  at  subnodes  of  $INDICES_OF_SUBS£T_ 
ELEMENTS 

points  as  subnodes  of  $COMPATIBILITY_ 

CRITERIA  equals  the  upper  limit  of  the  sum 
on  descriptor  values  allowed  to  be  compatible 
equal  to  the  value  of  $INDEX_OF_SUBSET_ 
ELEMENT,  used  as  an  index  of  $SET 
a pointer,  containing  the  value  of  the 
lower  bound  set  for  compatibility  by 
the  user 

a pointer,  containing  the  value  of  the  upper 
bound  set  for  compatibility  by  the  user 


$EQUALITY_CONSTRAINT 


a pointer,  containing  the  value  of  the 
equality  constraint  for  compatibility  as 
set  by  the  user. 
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2.4.19.11  COMMENTED  CODE 


COMPaTIBILITY.SeT.GENERATOR*  procedure 

/• 

*/ 

/* 

PURPOSE! 

• / 

/• 

GIVEN  A SET  OF  ELEMENTS  WITH  DESCRIPTORS* 

ENUMERATE  ALL 

/• 

compatible  subsets  of  The  original  sft,  a 

subset  is  determined*/ 

/• 

To  BE  compatible  IF  ITS  ELEMENTS  MEET  THE 

following  criteria. 

*/ 

/* 

*/ 

/* 

• SUM  OF  descriptor  VALUES  LESS  THAN  OR 

EQUAL  TO  A MAXIMUM 

• / 

/• 

eg,  SUM  OF  Element  weights  < 

200 

#> 

/• 

*/ 

/♦ 

• descriptor  VALUES  LESS  THAN  OR  EQUAL 

TO  A MAXIMUM 

*/ 

/* 

EG.  element, 1.  EN6TH  < 10 

*/ 

/* 

*/ 

/* 

. descriptor  values  greater  than  or  equal  to  a MINIMUM 

*/ 

/* 

EG.  element. POWER  '<  2 

*/ 

/♦ 

*/ 

/* 

• DESCRIPTOR  VALUES  FQUAL  TO  A VALUE 

*/ 

/* 

EG.  ELEMENT. PREVIOUSIUSAGE  « 1 

*/ 

/* 

• / 

/♦ 

element. COLOR  = »BLUE* 

#/ 

/♦ 

*/ 

/* 

INPUT! 

*/ 

/* 

*/ 

/♦ 

SSET  - the  Form  of  sset  is 

*/ 

/• 

SSET  , / 

EXAMPLE! 

*/ 

/♦ 

ELEMENT^ name  - / 

SSET 

*/ 

/♦ 

DESCpIPTOP  - VALUE  / 

EXPERIMENTjtA 

♦ / 

/* 

descpiptor  - value  / 

weight  - 50 

*/ 

/* 

etc.  / 

LENGTH  - 1? 

*/ 

/* 

element^name  / 

EXPEoIMENTlB 

♦ / 

/* 

etc.  / 

weight  - If, 

*/ 

/* 

/ 

LENGTH  - 9 

♦ / 

/* 

♦ / 

/* 

SCOMPATIBILITY.CRITERIA  - THE  FORM  OF  SCOMPATIBILITY^CRITERI A*/ 

/* 

IS 

*/ 

/* 

*/ 

/* 

$COMPATIBtLITY_CRJTERIA 

*/ 

/* 

UPPERj  IMIT»ON_dESCRIPTOP 

!„SUM 

#/ 

/* 

DESCRIPTOR  - VALUE 

*/ 

/♦ 

DESCRIPTOR  - VALUE 

*/ 

/• 

ETC. 

*/ 

/* 

descriptor:.value-Upper_limit 

*/ 

/• 

DESCRIPTOR  - VALUE 

*/ 

/• 

ETC. 

#/ 

/* 

descriptor!:valuej.ower_limit 

• / 

/* 

descriptor  - VALUE 

»/ 

/♦ 

ETC. 

#/ 

/* 

DESCRiPTORiVALUE-EQUALITY 

• / 

/* 

descriptor  - VALUE 

*/ 

/* 

ETC. 

*/ 

/♦ 


ANY  element  of  SSET  WHICH  DOES  NOT  HAVE  A #/ 
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/* 

/• 

/* 

/♦ 

/♦ 

/♦ 

/* 

/♦ 

/* 

/# 

/* 

/♦ 

/♦ 

/* 

/♦ 

/* 

/* 

/♦ 

/♦ 

/♦ 

/* 

/* 

/* 

/* 

/* 

/• 

/* 

/* 

/♦ 

/* 

/♦ 

/♦ 

/* 

/* 

/♦ 

/* 

/♦ 

/* 

/* 

/* 

/* 

/* 

/* 

/♦ 


/* 


descriptor  of  each  type  included  in  */ 

SCOMPATIBILITY.CRITERIA  will  not  be  considered  */ 

eligible  for  a compatible  subset,  elements  may  */ 
HAVE  other  descriptors  BUT  WILL  ONLY  BE  TESTED  ON*/ 
THOSE  included  IN  sCOMPATIBILITY  CRITERIA*  */ 

*/ 

#/ 

OUTPUT: 

SC0MPATI8LE.SUBSET.TREE 

THE  FORM  OF  SCOMPaTIBLE.SUBSET.TREE  IS  */ 

*/ 

fCOMPATiBLE-SuBSET-TREE 

INDEX  f/ 

INDEX 

Index 

INDEX 

INDEX 

Index 

etc. 

THE  indices  of  THE  ELEMENTS  OF  SSET  WHICH  ARE  ELEMENTS  #/ 

OF  compatible  SUBSfTS  are  output  as  labels  of  THE  NODES  */ 

OF  SC0MPATIRLE.SU8SET.TREE.  EACH  BRANCH  CONTAINS  THE  #/ 

indices  of  a compatible  subset.  */ 

* - 

example:  SCOMPATlBiElSURSETHTREE 

2 f / 

5 */ 

7 

9 

7 

9 

9 */ 

5 f/ 

7 */ 

9 f/ 

9 */ 

7 

9 

9 

*/ 

The  top  most  branch  represents  the  subset  */ 


*/ 

(SSET(2) *SSET(5) *SSET(7) tSSET (9)  )•  */ 

*/ 

( SSET*  SCOMPaTIBILITY.CRITERIA.  SCOMPATIBLE.SUBSET.TREE) 

OPTIONS (EXTERNAL) I 

*/ 

DECLARE  iNDEX.OF'SET.ELFMENTf  COMPAtIBLE.ELEMENT.FLAG* ^ 

SINDICES^OF.SUBSET.ELEMENTS#  COMPATIBLE.SUBSETIFLAG, 

index.ofIchild*index.first.possible.grandchilD* 

ooubletIpreviously.checked.flag* 
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iNDEX^IRSTt  INdEX^SECONO 


LOCALI 


/* 

/* 

/* 

/• 

/* 


*/ 

»•««  generate  first  levfl  subnodes  of  »**  f/ 

****  *CoMPATIBLE.SuBSET_TREE  as  indices  of  compatible  */ 
subsets  of  Cardinality  i *•* 

*#*♦  ^ . ***  *>' 

PRUNE  SCOMPATIBLeIsuBsET^TREE  I 

IN0EX10F.SET_ELEMENT  * 0 | 

DO  FOR  ALL  S^BNOOES  OF  SsET  USING  SSET.ELEMENT  I 

indexIof^set.element  . INDEX_0F«SET_ELEMENT  ♦ I I 
CALL  check' ELEMENT^COmPATIPILITT ( sset_element f 

SCOMPATiBiLITY.CRITERlAt 
C0MPATIBLE_ELEMENT_FLAQ)  I 

IF  C0MPATIBLE1eLEMENT’"ElA6  » 1 

THEN  OOl  $INDICES«0F.SUBSET1ELEMENTS (FIRST) « 

INDEX;:0F„SET.ELEMENT» 

CALL  CHECK_DeSCRIPTORi:VALUE«SUMS(SSET# 

SINDICES_OF^SUBSET_ELEMEnTS« 
SCOMPATIBILITY.CRITERIA* 
COMPATIBLE.SUBSETi^FLAG)  I 
IF  compatiblf^subsetIflag  * 

Then  label ($compat!ble«subset_tree (next) ) 

» index.of.set«element  * 


END! 

/***# 


generation  of  first  level  subnodes  ***/ 


/ 


♦ 1 ) 


end  I 

/• 

/#  GENERATE  SECOND  LEVEL  NODES  OF  $COMPATIBLE_SUBSET^TREE  AS 
/#♦*  COMPATIBLE  SUBSETS  OF  CARDINALITY  2 (DOUBLETS) 

/* 

DOUBLET„PREVIoUSlY«CHECKeD_FLAG  » 01 
DEFIN5:  SFAMILY^HEAD  as  SC0MPATIBLE-SUBSET_TREE  I 
INDEX-OF.CHILD  ■ 0 I 

DO  FOR  ALL  SUBNODES  OF  SFAMli  Y.HEAD  USING  SCHILD  I 
INDEX.OF*  Child  * INDEx_OF3:ChILD  ♦ 1 » 
INDEX_FIRST.P0SSIBLE^GRANDCHILD  = index_of,„child 
DO  INOEX-OF.POSSIBLE'grANDCHILD  ® 

INDEX_FIRST^POSSIrLE_GPANOCHIlO  to  number ($FAMILY«HEAD) 
INOEXIFIRST  * LABFL(SFAMILY-HEAD(INOEX«OF_CHIlD) ) » 

index_second  = ^ , 

label (1!FAMILY«HEAD(INDEX«OF.POSSI8LE_6RANOCHIlO) ) % 
CALL  CHECkIdOUBLET-COMPATIBILITY 
(INDEX  FIRST,  INDEX.SECOND* 
DOUBLET.PREvlOUSLY^CHECKED.FLAGf 
COMPATIBLE_DOU0^ET_FLA6)  I 
IF  C0MPATIRLEJ30UrLET!^FLAG  * I 
THEN  DOJ  LABEL(5ChILD(NEXT) ) = 

label (SFaMILY.HEAD(INDEX_0F.P0SSIBLE_6RANDCHI| 
IF  NUMBEr(SCHILD)  = 1 

THEN  SUNfXAM1NED_FAMILY_HEADS (NEXT) (FIRST) e 
INdEX'*OF_CHII-D  I 

endi 


**•/ 

*/ 


D)  ) I 
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END! 

END!  /*♦*  generate  SECOND  LEVEL  NODES  *•*/ 

/*  */ 

/*♦  GENERATE  ALL  NODES  BELOW  THE  SECOND  LEVEL  BY  SUCCESSIVELY  ##/ 

/**  examining  family  heads*6enerating  new  ones  as  necessary  *•/ 

/•  */ 

doublet_previously_checkfd1flag  « n 

EXAMINE.NEXT^EAMILY.HfaD J 

call  6ENERATElFAMILY«GRANDCHlLDREN(SUNEXAMINED„FAMILY_HEA0S(FTRSTi 

. r ' * 

PRUNE  SUNEXAMINED_FAMILY-  HEADS (FIRST) I 
IF  SUnEXAMINFD_FAMILY.HEaDS (FIRST)  IDENTICAL  TO  SNULL 

.then  returni 

ELSE  GO  TO  FXaMInE.NEXT_FAMILY_HEAO  I 


/*  #/ 

GENERATeIfAMILY^GRANDCHILDrEN)  procedure  (SFAMILY^HEAD.INDFX) I 
/*  */ 

/*♦♦  GIVEN  the  Indices  of  The  family  head*  generates  grandchildren  */ 

/*♦*  BY  LOOKING  FOR  POSSIBLE  DESCENDANTS  OF  EACH  CHILD 

#/ 

/•**  FIRST*  Trace  through  scompatibleLsubsetItree  to  find  the  #/ 

/***  FAMILY  head  INDICATED  BY  SFAMILY«HEAD_INDEX  */ 

/*  */ 


PRUNE  SINOlCES_OFiPOSSIBLElNEW.SUBSET  | 

DEFINE  SFAMILY-HEAD  AS  $COMPATIBLE«SUBSET1tREE  I 
DO  I a 1 TO  NUMBER(SFAMli  YIhEAD.INDEX) I 
MEMBER.INOEX  « $FAMILY«HfAD.1N0EX(I)  I 
DEFINE  SFAMILyIhEAD  AS 

$FAMILY.HFAD (MEMBER-INDEX)  I 
$IN0ICEs10F.P0SSIBLE.mEW_SUBSET<I)  ■ LABEL(SFAMILY_HEAD) I 
END?  /***  TRACE  DOWN  TO  FAMILY  HEAD  <»*♦/ 

/•  */ 

/**  SEARCH  FOR  DESCENDANTS  OF  EACH  CHILD  **»/ 

/*  i/ 

INDExIoF^CHILD  * 01 

DO  for  all  SUBNODES  of  SFAMILY.HEAD  using  SCHILD  I 

SlN0ICES^0F„P0SSIBLE«NEW.SU8SEf(NEXT)  s LABEL ( JCHILD) I 
INDEX.OF^GHILD  a iNDEx.OFiiCHlLD  ♦ 1 I 
INDEX^FlpST-POSSIBLE-RRANDCHlLn  » INDEX.OF^CHILD  ♦ 1 I 

DO  index_of.possible«granochild  « 

IN0EX_FIRSt1P0SSIBLe1graNDCHILD  to  number (SFAMILYIHEAD)  I 
INDEX^FIRST  a LABEl($CHILD) I 
INOEX.SECOND  a 

LABEL (5FAMILY_HEaD(InDEX'_oF.POSSIBLE«GRANDCHIlD) ) I 
CALL  CHFCKIdOUBLET'COMPATIBILITYC  INDEX.FIRST»INDEX_sEcoND*’ 
D0UBLET^PRFVI0USLY^CHECKED_FLAG* 
COMPATIBLE^OOUBLET.FLAG  ) I 

/*  * 
/#**  IF  doublet  passes  Test*  check  the  whole  subset 


/♦ 


IF  COMPATlBLE^DOUBi.’ET.FLAG  a 


« 
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THEN  DOl  SINOICES_OF1poSSIBLE«-NEW_SU3SET(NEXT) 

■label (SFAMlLYlHEAD(lN0EX.0F_P0SSI8LE.GRANDCHlLn) ) t 
call  CHECKfOESCRIPTOR.VALUElsUMS 

( $SEf*  SINDICES_oF_POSSI8LE_NEW_SUBSET. 
$COmPATIBILITY„CRITERTA» 
COMpATIBLE.SUBSET.FLAG)  I 

/•*  IF  POSSIBLE  grandchild  HAS  PASSED  ALL  TESTS*  ADD  HIM  TO  THE  TrfE  »/ 

IF  C0MPATIbLE_SUBSET«FLA6  a 1 

then  doi  Label (schild (mext) ) 

■LABEL < $FAMILY_HEA0 

< INOEX.OF^POSSIBLE.GRANDCHILD)  i I 
If  NUMRER($CHILD)  = 1 

Then  doi  *unexamined_family_heads(next(  ■ 
SUNEXAMINED„FAMILY_HEADS(FirsT> I 
SUNEXAMINED«FAMILY.HEADS(LaST) 
(NEXT)  «INDEX_0F.CHILD  I 

END  I 

endi  ' 

PRUNE  SlNOiCES^OF_POSSIBLE_MEW_SUBSET CLAST)  I 

endi 


ENDI 

PRUNE  *INDICES10F.P0SS1BLE_NEW1SUSSET(LAST) I 
ENDI 

END!  /***  GENERATE.FAMILY^GRANOCHILDREN  *»»/ 
CHECK^DOUBLET.GoMPATIBlLlTy:  PROCEDURE 

(INDEX„FIRST*INDEX_SECOwD,OOUBLET^REVIOUSLY„CHECKE01.FLA6, 
COMPATIBLEIdouRLET.FLAS)  I 

/* 

/*♦*  IF  DOUBLET  HaS  PREVlOUSi  Y BEFN  CHECKED*  JUST  LOOK  UP  THE 
/*  RESULTSI  OTHERWISE*  TREaT  DOUBLET  AS  UNCHECKED  SUBSET  OF 

/*  Cardinality  2 


#/ 

#> 

*/ 


IF  ooublet^previously.checkedIflag  = 0 
then  doi 

PRUNE  SInOICES^Of.^UBSETIeLEmENTS  I 
SINOIcES_OF_SUBSeT  elements (FIRST) a INOEX^FIRSTI 
$INDICES_0F_SUBSeT^ELEMENTS(2)  a INDEX.SEcoNDI 
CALL  CHECK.DESCRtPTOr1vALUE~.SUMS 

(SSET*$lNDlrES.pF.SUBSET„ELEMENTS* 
$C0MPATlBlLlTYi;rRnERlA»C0MPATIBLE.00UBLET.FLA6)  I 

RETURN! 


ENDI 

ELSE  DOI 

COMPATIBLE.DOUBLfTIFLAG  s 01 
DO  FOR  All  SUBNOdES  of  SC0MPATIBLE.SUBSET.TREF 
USING  SCURREnTIe^EMENTI 
IF  label (5CURrENT_FLEMENT)  > INDEX.FIRST 
then  return I 

IF  LABEL (SCURrENTIeLEMENT)  a INDEX.FIRST 

then  doi  do  For  all  subnodes  of  ScURRENT.ELEMENT  using 

SCURRENT.SECONO.ELEMENT I 
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IF  Label (scurrent^second^elemenT) >inoex1sfcond 

THEN  RETURN! 

IF  Label ($CURRENT.SECONO«ELEMENT)»lNDEx!iSFCOND 
Then  DOI  rOMPATIBLE^OOUBLET.FLAG  s ll 
RETURN! 

EnD! 

END* 

END! 

END! 

END! 

END!  /***  CHFCKIdOUBLET^XOMPATIBILITY  **«/ 


/*  */ 

CHECK_ELEMENT_G0MPATIBILITY!  procedure 
/*  */ 

/*  checks  the  descriptor  VAi  UES  of  an  element  against  upper  LiMTTti/ 
/*  LOWER  limit*  and  equality  CONSTRAINTS  «> 

/*  . «/ 
(*SETlELEMENT*$COMPATlBli  ITY^CRITERIA.  COMPATIBLE.ELEMENT.FLAO)  ! 
COMPATIBLE_ELEMENT_FLaG  s 1! 

/*  ****  CHECK  descriptors  CONSTRAINED  TO  BE  EQUAL  #/ 

DO  FOR  ALL  SUBNOOES  OF 

SCOMPATIBILITY.CRiTERIA.DESCRIPTOR^VALUE.EQUALITY 


Using  sequality_constraint  ! 

IF  SSET«ELEMENT.#LABEL(SEQUALITY«C0NSTRAINT)  identical  to  $NULi‘ 

I SSET^ELEMENT,#LABEL(SEQUALITY-CONSTRAINT)-.s 

SEQUALITY^CONSTRATNT 

then  DO!  COmPATIBLE^ELFMENT^'FLAC  s 0 ! 

RETURN! 

END! 

END! 

/• 

/**#*  CHECK  descriptors  CONSTRAINED  BY  UPPER  LIMITS 
DO  FOR  ALL  SUBNOOES  OF 

$C0MPATI8ILITY_CRJTERIA.DESCRIPT0R.VALUE_UPPER.LIMIT 
Using  suppEr.limiT! 

IF  SSET_ELEMENT.#LABEL($UPPFR_1,IMIT)  IDENTICAL  TO  SnULi’ 

I $SET_ELEMENT*WLABEl(SUPPER_LIMIT>  > supper^limit 
THEN  DO!  COMPATIBLE.ELEMENTIflAG  » 0! 

RETURN! 

END! 

END! 

/♦  */ 
/♦  *«#*  CHECK  descriptors  CONSTRAINED  BY  LOWER  LIMITS  */ 

DO  FOR  ALL  SUBNOOES  OF 

$COMPAtIBILITY.CRTTERIA.DESCRIPTOR1vALUE«LOWER_LIMIt 
USING  SLoWErIlIMIT  ! 

IF  SSET.ELEMENT.#LABEL(SLOWER_^IMIT)  IDENTICAL  TO  SwULi’ 

I $SET_ELEMENT,#LABEl{SLOWER_lIMIT)  < slower.limit 
THEN  DO!  COMPATIBLE.FLEMENT.FLAG  « 0! 

RETURN! 

END! 
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END! 

DO  FOR  ^*“^^^JJ®p2°j|j,_jy,^<j,pijppj^^UPPER_LIMlT.ON»DESCRIPTORlsuM 

USING  SSUM^UPPER^LIMIT  I 
IF  $SET_ELEMENT.#LABEL(SSUM«UPPER-LIMIT) 

identical  to  snull 

THEN  DO|  COMPATIBLE^FLEMENT^FLAG  = Of 
RETURNI 

ENDt 

END! 

END  I /*  CHECK_ELEMENT_C0MPATIBILITY 


/* 

/• 

/* 

/* 

/♦ 


CHECK  DESCRIPTOR.VALUE.SUMSJ  PROCEDURE 

CHECKS  UPPER  limit  CONSTRAINTS  ON  DESCRIPTOR  VALUE  SUMS 

( $SET*  SINOICES  of  SUBSFTlELFMENTStfCOMPATiBiLITY.CRiTERI At 

”pOMPATlBLE^SUBSET-FLAG  ) I 
C0MPATIBLE_SUBSET«FLA6  « 1 I 

DO  FOR  ^^‘-j^^^^pJ^jljJjyYicRlTERlA.UPPER.LlMlT.ON^DESCRIPTOR.SlJM 

USING  SSUM.UPPER.LIMIT  I 

DESCRIPTOR^SUM  a 0|  . ^ 

DO  FOR  ALL  SUBNODES  OF  SINOICE^^F-SUBSET^ELEMENTS 
USING  «INOEX_OFj£SUBSET_ELEM£NT» 

INOEK  * $lNDEX.OF.SUBSET_ELf:MENT  I 
DESCRlPTOR_SUM  = DfSCRIPTORiSUM 
♦ SSET ( INDEK) .#LAbEL(SSUM_UPPER_LIMIT)  I 

END!  ♦ . 

IF  DESCRIPTOR^SUM  > SsUM«UPPEReUIMIT 
THEN  DOI  COMPATIBLE.SUBSET.FLAG  = 0 I 
RETURNI 

ENDI 

ENDI  , ■ , 

ENDI  check  DESCRlPTORi;VALUE-SuMS  */ 

ENDI  /***  COMPaTIBILITY^SfTIgENERATOR  «**/ 


«/ 

*/ 

*/ 

*/ 

»/ 
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2,4.20  FEASIBLE  PARTITION 
GENERATOR 


2.4.20  FEASIBLE_PARTITION_GENERATOR 
2.4.20.1  Purpose  and  Scope 

Given  a partition  of  the  positive  integer  N containing  precisely 
M feasible  parts  taken  from  the  set  K-  {1,2,...K}  each  element  k 
of  which  has  a specified  maximum  numer  of  repetitions  r^^,  generate 
the  next  such  feasible  partition  in  decreasing  lexicographic  order. 
On  the  initial  call  to  the  module  the  highest  lexicographically 
ranking  partition  is  generated.  On  the  subsequent  call  after  the 
lowest  lexicographically  ranking  feasible  partition  is  generated, 
a flag  is  returned  indicating  that  the  set  of  feasible  partitions 
has  been  exhausted . 

The  intended  use  of  the  module  is  to  establish  sets  of  feasi- 
ble cardinalities  for  the  partitioning  subsets  of  the  "Set  Par- 
titioning" problem.  Since  for  scheduling  it  is  desirable  to 
have  all  parts  of  the  partition  approximately  equal  those  of 
highest  lexicographic  rank  are  considered  first. 

For  large  N and  small  K,  there  are  considerably  fewer  feasi- 
ble partitions  than  unrestricted  ones.  For  example,  suppose  N=25, 
M=10,  and  K=4 . Suppose  the  repetition  limits  are  120,  40,  10,  3 
for  the  parts  1,  2,  3,  and  4 respectively.  Then  there  are  more 
than  80  unrestricted  10-part  partitions  of  25  whereas  there  are 
only  17  feasible  partitions.  Clearly,  then,  some  procedure  is 
necessary  to  eliminate  the  infeasible  partitions  if  partition 
analysis  is  to  expedite  the  solution  of  the  set  partitioning  prob- 
lem. 
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2.4.20.2  Algorithm  Description 


The  generation  of  the  next  lower  lexicographic-ranking  par- 
tition of  the  positive  integer  N containing  precisely  M feasible 
parts  taken  from  the  first  k positive  integers,  each  with  its 
respective  repetition  limit  r^^,  is  best  done  recursively.  Three 
key  ideas  are  involved.  First,  the  highest  lexicographically 
ranking  unrestricted  partition  of.  any  positive  integer  involving  M 
parts  can  be  found  using  the  "division  algorithm"  on  the  ring 
of  integers.  Thus,  there  exists  a unique  integer  q called  the 
quotient,  and  r called  the  remainder  such  that 

[1]  N = Mq  4-  r and  0 ^ r ‘ q. 

The  highest  lexicographically  ranking  unrestricted  M-part  parti- 
tion of  N is  then 
M 

[2]  q,  . . . . ,q,qH-l,  . .^.  - 
M-r  parts  r parts 

Note  that  this  partition  has  at  most  one  break  part.  A part  of  a 
partition  is  called  a break  part  when  it  is  strictly  larger  than 
its  preceding  part.  Partitions  are  arranged  in  Increasing  order 
of  their  parts. 

The  second  basic  concept  is  that  the  next  lower  ranking  un- 
restricted M part  partition  N can  always  be  obtained  from  its 
predecessor  by  the  following  four-step  procedure: 

1)  Select  the  least  significant  break  part  (£),  excluding  the 
last  break,  in  the  preceding  partition. 
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[3] 


2)  If  part  i has  the  value  1,  no  more  partitions  exist;  there- 
fore exit  the  procedure.  (Note  that  only  the  first  part  can 
become  a break  part  while  it  is  one.  When  the  first  part  is 
the  least  significant  break  part  and  it  has  the  value  unity, 
the  set  of  M-part  partitions  of  N have  been  exhausted.) 

3)  Decrement  part  I by  one. 

4)  Replace  the  final  parts  of  the  preceding  partition  by  the 
highest  lexicographically  ranking  M-£  part  partition  of  N 
less  the  first  £ parts. 

The  final  fundamental  idea  is  that  upper  bounds  must  be  placed 
ojj  the  respective  partition  parts  to  eliminate  infeasible  parti- 


tions . 


A reasonably  tight  bound  on  each  part  can  be  derived  from  the 
set  of  available  parts  and  their  respective  repetition  limits. 
Define  the  M-term  sequence  s^  inductively  as 
Tk  for  M-r^  m ^ M 


£ for  ”■  ^ 


JLN. 

-E 


k=(i+l 


QJiQavXy  s is  an  upper  bound  on  the  m part  of  any  feasible  parti— 
m 

tion.  Although  the  respective  parts  of  a partition  could  fall 
below  these  upper' bounds  and  the  partition  still  be  infeasible 
because  a given  part  is  repeated  too  many  times,  this  s'«,  tuation 


is  unlikely  in  practical  set  partitioning  problems  because  r^  de- 
creases exponentially  with  k so  that  only  r^,  is  binding. 

The  adaptation  of  the  procedure  for  recursively  generating 
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unrestricted  M part  partitions  of  N to  a procedure  for  generating 
feasible  partitions  in  terms  of  the  above  upper  bounds  is  direct. 
Only  the  following  three  steps  need  be  added  to  the  procedure 
outlined  earlier. 

5)  If  none  of  the  final  £+1  parts  exceeds  its  upper  bound  then 
gxit  the  procedure  with  desired  feasible  partitxon. 

6)  If  there  is  a break  part  more  significant  than  £,  ^reset  £ 

to  the  index  of  the  next  most  significant  part  and  return  to 
step  2. 

7)  No  more  feasible  partitions  e‘/ast;  therefore,  exit  the  pro- 


cedure . 


2.4.20.3  Module  Input 

1)  Positive  integer,  N,  to  be  partitioned 

2)  Number,  M,  of  parts  (not  necessarily  distinct)  required  in 
each  partition 

3)  Largest  part,  K,  permissible 

4)  Set  i r ^ of  maximum  number  of  repetitions  for  each  per- 

' ^ kj£=l 

missible 

5)  Flag  indicating  that  current  call  is  the  initial  one  and  that 


the  first  feasible  partition  must  be  generated 
2.4.20.4  Module  Output 

1)  Next  partitioh,  v in  de^cFeasin^^ 

The  parts  of  a given  partition  are  ordered  in  the  monotonic 

,‘i  i ( ■ 

nondecreasing  order  of  their  indices. 

2)  F1P5>  indicating  that  the.  set  of  feasible 'partitions  has  been 


exhausted 


2.4.20.5  Functional  Block  Diagram 


© 
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til  « 

otes*  1.  Generation  of  the  upper  bound  on  m partition  part 
rsee  Equation  [3]  of  the  Algorithm  Description) 

2.  Generation  of  highest  lexicographically  ranking  partition 
(See  Equation  [1]  of  the  Algorithm  Description) 
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2.4.20.6  Typical  Application 


Suppose  N payloads  are  to  be  flown  in  M flights  and  that  the 

compatible  payload  sets  are  given.  Let  the  cardinality  of  the 

largest  compatible  payload  set  be  K.  Let  r,  be  the  number  of 

k 

compatible  payload  sets  of  cardinality  k.  Then  the  FEASIBLE_ 
PARTITI0NJ3ENERAT0R  module  will  generate  one  at  a time  and  in 
decreasing  lexicographic  order  all  of  the  feasible  ordered  se- 
quences of  payload  cardinalities.  The  most  desirable  ordered 
sequences  or  partititions  from  a scheduling  point  of  view  are 
those  whose  elements  are  approximately  equal.  This  is  true  be- 
cause statistically  speaking  each  compatible  payload  set  will  be 
equally  readily  scheduled,  that  is  some  sets  will  not  be  made 
easy  at  the  expense  of  making  others  difficult  to  schedule.  The 
partitions  resulting  in  the  most  nearly  equal  payload  cardinalities 
are  those  of  the  highest  lexicographic  rank.  Hence,  the  module 
begins  with  these  so  that  a schedulable  combination  of  compatible 
payload  sets  will  be  found  as  early  as  possible  in  the  enumera- 
tion process. 

2.4.20.7  References 
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2.4.20.8  DETAILED  DESIGN 


This  module  partitions  a positive  integer  into  a specified  number 
of  parts  which  can  take  on  the  values  of  1,  2,  3 . . . LARGEST_PART, 
obeying  constraints  on  the  maximum  number  of  repetitions  allowable  for 

each  value. 

If  a partition  is  input  to  the  module,  the  next  feasible  partition 
of  lower  rank  is  returned.  If  no  partition  is  input  to  the  module  and 
the  INITIAL_PASS_FLAG  is  set,  the  feasible  partition  of  highest  rank 
is  returned.  If  a partition  is  input  and  no  feasible  lower  rank  parition 
exists,  the  N0_L0WER_RANK_PARTITI0N_FUG  is  set.  Thus,  the  entire  set 
of  feasible  partitions  can  be  successively  enumerated. 
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2.4.20.9  INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 


LARGEST_PART 

INTEGER_FOR_PARTITIONING  - 
NUMBER_OF_PARTS 

$MAXIMUM_REPET IT IONS 


NUMBER_OF_PARTS_MINUS_l  - 

NO_LOWER_RANK_PARTITIONS_ 

PUG 

INITUL  PASS  FUG 


INDEX_OF_PART 
$ INTEGER_PARTITION 


input,  largest  value  any  part  may  take; 
defaults  to  INTEGER_FOR_PARTITIONING  minus 
NUMBER_0F_PARTS  plus  1 

input,  positive  integer  to  be  partitioned 
input,  number  of  parts  into  which  the  integer 
is  to  be  partitioned 

$MAXIMUM_REPETITI0NS(I)  = the  maximum  number 
of  times  a part  of  value  I may  appear  in  a 
feasible  partition.  If  $MAXIMUM_REPETITIONS 
does  not  have  a value  input  for  ear-h  I from  1 
to  LARGEST_PART,  $MAXIMUM_REPETITIONS  (I)  is 
set  to  NUMBER_OF_PARTS . 
equal  to  NUMBER_OF_PARTS  minus  1. 

- output,  equal  to  1 if  no  feasible  partition 
of  lower  rank  than  the  input  partition  exists 
if  equal  to  1 then  the  highest  rank  feasible 
partition  will  be  generated 

if  equal  to  0,  the  next  highest  rank  feasible 
partition  counting  down  from  input  $INTEGER_ 
PARTITION  will  be  generated 

an  index  which  varies  from  1 to  NUMBER_OF_PARTS 
an  output,  $INTEGER_PARTITION(I)  equal  to  the 
Ith  part  of  the  next  lower  rank  feasible 
partition  ordered  from  lowest  valued  part 
to  highest.  If  there  is  no  lower  rank  partition, 
a null  tree  is  returned. 
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$ LARGE  ST_FEASI.BLE_PART 


INDEX_OF_BREAK_PART 

INDEX_STARTER 

$NUMBER_OF_RE?ETITIONS 

$MAGN  ITUDEJ3P^PART 
INDEX^OFJIE  PET  IT  ION 
IPORT ION_ALREADY_ 
i PARTITIONED 

i NUMBERJDF_^MAINING_ 

PARTS 

i 

$ PART  IT  ION_AFTER_BRE  AK, 
PART 

INDEX_UPPER 

INDEX_LOWER 

ft 

t 

} 

1 
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- an  output,  $URGEST_FEASIBLE_PART(I)  is  an 
upper  bound  on  the  value  of  $INTEGER_PARTITI0N 
(I).  It  is  computed  on  the  initial  pass  of 
FEASIBLE_PARTITI0N_GENERAT0R  based  on  LARGEST_ 
PART  and  $MAXIMUM_REPETITIONS  and  used  for  all 
subsequent  passes.  It  is  only  output  so  that 
it  will  not  be  destroyed  when  leaving  the 
module  and  require  recomputing  on  each  subse- 
quest  pass 

- contains  the  index  of  $INTEGER_PARTITIC®J 
which  is  the  next  break  part. 

- equal  to  the  starting  point  from  which  the 
module  counts  backward  in  $INTEGER_PARTITION 
to  find  the  next  break  part 

- equal  to  1 plus  the  magnitude  of  the  partition 
contained  in  $INTEGER_PARTITION 

- points  at  subnodes  of  $INTEGER_PARTITION 

- equal  to  the  value  in  $MAGNITUDE_OF_PART 

- the  difference  between  INTEGER_FOR__PARTITIONING 
and  the  portion  already  partitioned 

- the  difference  between  NUMBER_0F_PARTS  and 
1NDEX_0F_BREAK_PART 

- equivalent  to  $L0CAL_PARTITI0N,  equal  to  the 
number  of  elements  to  be  partitioned  per  part 

- equal  to  NUMBER__0F_PARTS 

- equal  to  the  difference  between  the  number 

of  parts  and  the  maximum  number  of  repetitions 
allowed  plus  1 


IPART_VALUE 

INTEGER_QUOTIENT 

LOCAL_INTEGER 
LOCAL_NUMB  ER_OF_PARTS 
INTEGERJEIEMAINDER 

INTEGER  QU0TIENT_PLUS_1 


an  index,  decremented  from  LARGEST_PART  to  1 
ratio  of  number  to  be  partitioned  to  the  number 
of  parts 

equal  to  the  nuiiber  to  be  partitioned 
equal  to  the  number  of  parts 
the  remainder  as  a result  of  calculating 
INTEGER_QUOTIENT 

equal  to  the  value  of  INTEGER_QUOTIENT  plus  1 


C ■ ^ 
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2.4.20.10  COMMENTED  CODE 


FEASIBLE_PARTITION_GENERAToRi  procedure 
/♦  ♦/ 

/#  purpose* 

/*  partition  a Positive  intfger  into  a specified  number  of  parts  */ 

/#  WHICH  CAN  TAKE  ON  THE  VALUES  1 *2*3, . , ,LARGEST„PART*  OBEYING  */ 

/♦  CONSTRAINTS  ON  THE  MAXIMUM  NUMBER  OF  REPETITIONS  ALLOWABLE  FOR  •/ 

/*  EACH  VALUE,  ■*/ 

/♦  4/ 

/•  IF  A partition  is  INPUT  TO  THF  MOOULEf  THE  NEXT  FEASIBLE  4/ 

/♦  PARTITION  OF  LOWER  RANK  WILL  BE  RETURNED  , 4/ 

/*  IF  NO  PARTITION  IS  INPUT  TO  THE  MODUi  E AND  THE  INITIAI PASS^FI  AG4/ 

/*  IS  SET.  the  FEASIBLE  PARTITION  OF  HIGHEST  RANK  IS  RETURNED.  4/ 

/*  IF  A PARTITION  IS  INPUT  AND  NO  FEASIBLE  LOWER  RANK  PARTITION  4/ 

/♦  EXISTS*  the  N0J.0WERJRANk«PARTITI0N.FlA6  IS  SET.  4/ 

/♦  THUS*  THE  entire  SET  OF  FEASIBLE  PARTITIONS  CAN  BE  SUCCESSI VEi'Y  4/ 

/•  ENUMERATED,  4/ 

/♦  4/ 

/♦  NOTE*  RANK  IS  DETERMINED  BY  THE  MAGNITUDE  OF  THE  LOWEST  VALUER  4/ 

/»  part  of  the  partition*  TIES  BROKEN  BY  THE  MAGNITUDE  OF  4/ 

/*  THE  SECOND  LOWEST  VALUED  PART  ETC.  4/ 

/•  4/ 

/*  example*  THE  PARTITIONS  OF  THE  INTEGER  6 INTO  3 PARTS  RANKED  4/ 

/*  from  HIGH  TO  LOW  ARE*  (2*2*2)  4/ 

/♦  (1*2*3)  4/ 

/♦  (1*1*4)  . 4/ 

/*  (NO  LIMIT  ON  Part  size  or  number  of  REPITITIONS)  4/ 

/♦  4/ 

/♦  INPUT*  4/ 

/•  4/ 

/*  INTE6ER«F0R.PARTITI0NING  - POSITIVE  INTEGER  TO  BE  PARTITIONED  4/ 

/*  NUMBER_0F_PARTS  - NUMBER  OF  PARTS  INTO  WHICH  THE  INTEGER  IS  TO  4/ 

/♦  BE  PARTITIONED  4/ 

/*  LARGEST^PART  - LARGEST  VaLUE  ANY  PART  MAY  TAKE  4/ 

/♦  defaults  to  INTEGER-/0R_PARTITI0NING  - 4/ 

/♦  ^ (NUMBER.OF.PARTS  - 1)  4/ 

/*  smaximum.repetitions  » smaximumIrepititions ( I ) a the  maximum  4/ 

/♦  number  of  times  a part  of  value  I MAY  4/ 

/♦  APPEAR  in  a feasible  PARTITION.  4/ 

/*  IF  smaximumIrepetitions  does  not  havf  a4/ 

/•  VALUE  INPUT  FOR  EACH  1 FROM  1 TO  4/ 

/*  LARGFSTIpART*  $MAXIMUM.REPETITI0NS(I)  4/ 

/•  IS  SFT  TO  NUMBER.OF.PARTS,  4/ 

/*  INITIAL„PASS.FLAG  - *1  HIQHFST  RANK  FEASIBLE  PARTITION  WILL  BE4> 

/*  GENERATED  4/ 

*0  NEXT  highest  RANK  FEASIBLE  PARTITION  4/ 

/•  COUNTING, DOWN  FROM  INPUT  4/ 

/*  sintfgerLpartitton  will  be  generated  4/ 

/*  SINTEGER-PARTITION  - SInTEGER^PARTITION ( I ) IS  THE  I TH  PART  4/ 

OF  A partition  from  WHICH  THE  NEXT  LOWFSt4> 
/*  Rank  feasible  partition  will  be  generated4/ 

/•  If  INITIAl1pASS„FLAS  a 0.  4/ 
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/• 

/♦ 

/* 

/* 

/♦ 

/* 

/* 

/* 

/* 

/• 

/* 

/• 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/• 

/* 

/• 

/* 

/♦ 


The  parts  of  sintegeR-Partition  must  bf 
ordered  From  low  to  htgh*  lowest  value 

Part  ■ $lNTEGER>ARTlTION(i)  . 

The  input  partition  must  be  feasible# 


OUTPUT: 


/* 


/* 

/* 

/* 


siNTEGER  Partition  - sinteger^partitionci)  « i th  part  the 
**  next  lower  RmNK  feasible  partition  orderfd 

from  lowest  valued  part  to  highest# 

IF  THERE  IS  NO  LOWER  RANK  PARTITION*  A 
NULL  tree  is  returned# 


#/ 

#> 

*/ 

*/ 

• / 
*/ 
#/ 
#/ 
*/ 

#/ 


NO  lower  RANK'PARTITIONS'flAG  »1  NO  feasible  partition  OF  LOWER#/ 

“ TkiniiT  nAtsirTTTnki  m.  * 


slargest_feasIble_part  - 


IS  AN  UPPER 


RANK  than  the  input  PARTITION 
exists 

FLARGFST_FEASIBLE_PART ( I ) 

BOUND  ON  THE  VALUE  OF 
«INTEGER1pARTITION(I)  # 

tt  is  computed  on  the  initial  pass  of 
feasible1partition1.generator  based  On 
LARGEStIpaRT  and  smaximum.repetitions^ 

AND  USED  FOR  ALL  SUBSEQUENT  PASSES,  IT 

ts  only  output  so  that  it  will  not  be 
destroyed  when  leaving  the  module  AND„ 
require  recomputing  on  each  subsequent 

PASS. 


(INTEGER_F0R_PART I TlONlNG#NUMBER_OfMFARTS* largest.? ART* 

SMAXIMUM  repetitions* INI TIAL„PASS_FLAG*SINTE6ER^PARTITI0N* 
no^lowerIrank^partitions.flag*  SLARGEST_FEASIBLE.pART  ) 
OPTIONS(EXTERNAL) « 


♦/ 

#/ 

#/ 

#/ 

#/ 

*/ 

#/ 

*/ 

#/ 

t — 

*/ 

#/ 

#/ 

#/ 


DECLARE 


INDEX^OF' BREAK.PART*  I*  nUMBER_OF_PARTS_MINUS.1 » 
indexIstarter  * «NUMBFR_0F«REPETITI0NS*  index.of^art* 
$MA6nTtUDE«0F_PART*  index^of.repetition  local 


FILL  in  defaults  ON  L ARGEST_.PART  AND  SMAXIMUM.REPETITIONS 


#/ 


#/ 

'*/ 

*/ 


if  LARGEST-PART  < 1 ^ 

THEN  LARGEST  PART  * INTEGER.FOR.PARTITIONING 
DO  I s 1 TO  LARGEStIpART  « 

IF  SMAXIMUM.REPETITI0NS(I)  = ♦»  , 

then  SMAXIMUmIrEPFTITIONS(I)  * NUMBER^OF.PARTS 

number_of_parts1minus_i  ■ nUMBERL0F:-PARTS  - 1 I 

NOJ-OWERlRANK_PARTlTIONS_Fi>G  a 0 » 


- (NUMBER_0F_PARTS-1)  I 


/* 

/* 

/* 

/* 


IF  THIS  IS  NOT  The  initial 
otherwise  generate  highest 


PASS*  begin  ORDINARY  SEQUENCE* 
rank  partition 


*/ 

#/ 

#> 

*/ 
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IF  INITIAL^PASS^.FLA6  • 0 

THEN  CALL  NEXT_BREAK.PARTf«STARTING?i:FROM <NUMBER.0F_PARTS  MINUsIST)  | 
ELSE  DOI 

CALL  fEASIBLE^PARTlUpPER' BOUND  I 
IF  no_lower«rank^partitions.flag  « 1 
then  RETURNI 

CALL  HIGHEST«RANk.PARTITION  ( 1NTEGER„F0R«PARTITI0NINR* 

NUMBER-OF.PARTS* 
S1NTEGER.PARTITION)  I 
DO  INDEX„0F_PART  « 1 TO  NUMBER_OF1pARTS  I 

IF  *INTEGER_PARTlTlON(INDEX.OF_PART) 

> $LARGEST_FEASIBLE.PART(INDEX_Of1papT) 

THEN  DOI 

no_lower.rank1partitions.flag  ■ ll 
return I 

End  I 
endi 

GO  TO  CHECK.REPEtmON.LlMlTS  I 

ENDI 

/* 

TRY.ANOTHER.PARTITIONI 

IF  SINTEGER.PARTITION(INDEx.OF?^BREAK-PART)  a 1 
THEN  DOI 

PRUNE  SiNTEGERJ>ARtITION  I 
NO.LOWEr_RanK.PARTTTIONS.FLAG  a 1 ; 

RETURNI 
ENDI 

CALL  PARTITI0N.aT_kN0WN_8RfAK.PART  I 

/* 

CHECK.PARTlUPPERlBpUNDS I 

00  I a index_of_break.part  ♦ 1 TO  NUMBER.OF.PARTS  I 
IF  SINTEGER»PARTITI0N(I)  > SLARGEST.FEASI0LE.PART(I) 
then  DOI 

INOEX.STaRTER  a inoex_ofLbreak.part-  1 I 
Call  NEXT.BREAK;rPARTlSTARTlwG_FROM(INDEX.STARTER)  I 
60  TO  TRY.ANOTHfR  PARTITION  I 
END  I 

ENDI 


CHECK.REPETITI0N_LIMIT^: 

DO  I a 1 TO  LAPgEST.PART  I 

$NUMBER»0F_REPETITI0NS(T)  * 0 I 
endi 

DO  FOR  ALL  SUBNODES  OF  SINtEGErIpaRTITION  USING  SMAGNITUDE JOfIpaRTi 
. INDEX.OF.REPETITION  a SMAGNITtjDEloF.PART I 
SNUMBER.OF.REpETlTlONSdNDEXloF.REPETlTlON)  = 
SNUMBER_0F_REPETrTI0NS(lN0EXl0F  REPETITION)  ♦ I I 
ENDI 
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/* 

/• 

/* 

/• 


/♦ 

/* 

/* 


DO  I ■ 1 TO  LARGEST^PART  I 

IF  $NUMBER.OF«REPETITIOnS{I) 

> *MAXIMUM_REPETIT10NS(I) 

then  001 

call  K'EXT^BREAK^i^PART^STARTlNG^FROM 

(NUMBER.OF.PARTS.MlNUSil ) I 

60  TO  try.anothfrIpartition  I 

END  I 

END  I 

#/ 

*/ 

NEXT  BREAK«PART_STaRTIN6_FrOMI  procedure  ( INDEX.STARTER)  I 

FINDS  the  next  BREAK  PARTt  STARTING  AT  INDEX.STARTER  AND  */ 
counting  backwards  In  SINTEGER-PARTITION  »/ 

!N0EX«0f1.BREAK-PART  * 1 I 
DO  I * INDEX_STARTER  to  2 by  ^1  I 

IF  $INTE6ER_PARTITI0N(T)  > $INTEGER_PARTITI0N ( I-l ) 

then  do I 

index_of_break'part  * I » 
returni 

END! 

END! 

ENDI  /•  NEXT^BREAK^PArT_STARTIN6-FR0M  */ 

*/ 

PARTITION.AT  KNOWN_BREAK.PaRTI  PROCEDURE  I 

*/ 

DECLARE  IPOPTlON^  ALREADY? PARTITIONED* NUMBER-OF_REMaINING«PARTS» 

iremainder_to_beEpartttioned,spartition_after|break«part 

LOCAL  I 

$INTE6ER'PART1TI0N(1NDEX_0F.BREAK.PART)  * 

$INTEGER1paRT1TI0N(IN0EX.0F_BREAK_PART)  1 I 
iPORTrON.ALREADY-PARTlTIONFD  * 0 % 

DO  I a 1 TO  !NDEX_0F_BREAK?>PART  I 

IPORTTON.ALREADY  PARTITIONED  = IPORTION^ALREADY^PARTITIONEO 

♦ SINTEGER^PARTITION(I) I 


ENDI 

iremainder^to' BE^PARTITIONED  « INTEGER.F0R_PARTITI0NING 

- IPPRTION.ALREADY.PARTITIONED,  I 

NUMBER«0F_REMAININg1paRTS  * NUMBERLoF-PARTS  - INDEX.0F_BREAK_PART  t 
~ »/ 

CALL  HIGHEST  RAnK.PART I TIOn  ( IREMaINDER_TO_BE«PARTITIONED* 

MUMBER«OF„REMAINtNG_PARTS* 
SPAPTITI0N_AFTER«BREAK_PART)  I 
DO  I S 1 TO  NUMBER_0F.REMAtN1NG«PARJS  I 

$INTEGER_PARTiTIon(INDEX»’OF,0REAKwPART  ♦ I) 

B *PARTITI0N^AFTER_BREAK.PART(I) I 

END  I , 

END  I /*  paRTITION_AT«KmOWN£BREAK-PART  ♦/ 
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/♦ 


feasible.part^upperIbounoj  procedure  » 

DECLARE  iNDEX.UpPERt  INnEX^LOWER.  IPART.VALUE  LOCAL  I 

indexIlower  « numberIofIparts  -SMAXIMUM_REPETITI0NS(LARGEST.PART)MI 
DO  IPARTIvALUE  « LARGEST^PaRT  to  1 by  -1  » 

IF  INDEX.LOVER  < 1 THEN  INDEXILOWER  * 1 I 
DO  I a iNOEXi^LOWER  TO  INnEX^UPPER  S 

$LARGEST_FEaSIBLE_PART(I)  X IPART.VALUE  I 
END! 

IF  INpEX«LOWER  * 1 THEN  RETURN  I 

indexIlower  * indexIlowep  - smaximumIrepetitionsupart^value  -i)  i 
IF  ipart.value  * 1 

then  if  IndexIlower  > i , ^ , , 

THEN  00»  No'lOWER„PANK_PARTITIONS_FLAG  = 1 » 

return? 

end? 

end? 

END*  /*  FEASIBLE»PART_UPPER_B0UND  */ 


/* 

/* 


/* 


HIGHEST^RANK^PARTITIONS  procedure  f 

(LoCAL.INTEGER*LOCAL.NUMPER«OF_PARTS,*LOCAL«PARTITION)  ? 


DECLARE 


INTEGER.QUOTIENT^  INTfGERlREMAINOERf  I» 
iNTEGER.OUQTlENTfPLUS!!! 


LOCAL? 


*/ 

• > 


*/ 


*/ 


INTEGER*^  QUOTIENT  * LOCAI INTEGER  / LOCAI — NUMBER^OF^PaRTS  ? 

INTEGERlPEMMNOrR  . "'>«hi"r*L!NUMBER_OF_PARTS  • INTEGER.QUOTIFNT. 
DO  I*l  TO  L0CAL1NUMBER«0F«PARTS  - INTEGER^REMAINDER  ? 

$L0CAL«PARTITI0N(I)  * INtEGER»QUOTlENT  ? 

END? 

IF  INTEGER-REMAINDER  > 0 

THEN  '>0'j^^ggg„-OUgTIENT_Pi.:uS_}  = InTEGER_QUOTIENT  ♦ 1 t 

00  I X LOCAI NUMBEr_OFSPARTS  * INTEGER-REMAINDER  ♦ I 

fo  locallnumber^of^parts  I 

SLOCAL-PARTITIONII)  * INTE6ER.QU0TIENT.PLUS-I  ? 

END? 

END?  r 

END  ? HlGHEST_RANK|PARTlTIpN  */ 

end  ? /*  FEASIBLE-PaRTITTON.GENERATOR  <»/ 
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2.4.21  PROJECT  DECOMPOSER 


2.4.21  PROJECT_DE COMPOSER 

2.4.21.1  Purpose  and  Scope 

This  module  will  identify  all  subprojects  contained  within  a 
specified  project.  Frequently  these  subprojects,  which  are  some- 
times apparent  to  the  scheduler,  are  difficult  to  recognize  in  the 
complete  network.  Identification  of  the  subprojects  can  signif- 
icantly reduce  the  computational  effort  required  to  schedule  the 
entire  project  by  enabling  some  of  the  scheduling  analysis  to  be 
done  separately  for  each  subproject.  For  this  reason  the  follow- 
ing analytical  procedure  is  proposed  for  their  detection. 

2.4.21.2  Modules  Called 
None 

2.4.21.3  Module  Input 

Critical  path  input  data  $J0BSET 

$J0BSET 


2.4.21.4  Module  Output' 

Tree  defining  the  unique  subproject  decomposition  $J0BSET 
Subproject  identifier  (user  supplied  label) 

Member  activity  or  event  identifer 

Predecessor  of, activity  or  event  identifer 


$J0BSET 


2.4.21.5  Functional  Description 

In  order  to  construct  an  algorithm  for  identifying  "subprojects" 
this  term  must  be  precisely  defined.  A subproject  is  a subnetwork 
containing  all  the  predecessors  and  successors  of  its  member  ac- 
tivities. (These,  of  course,  do  not  include  the  events  START  and 
FINISH.)  Recall  that  a network  for  scheduling  purposes  is  a set 
of  activities  and  events  denoted  by  nodes  together  with  all  their 
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predecessor  and  successor  relationships  represented  by  branches. 
Clearly,  then,  each  activity,  i,  in  a network  belongs  to  a unique 
subproject  that  can  be  generated  inductively  as  f ollox-7s : 

1)  Initialize  setsTl  and  ^ to  the  singleton 

successor  sets  of  activity  j , respectively 

3) SC<-77F-?nr\[lfly^  U,j}] 

4)  It^-  -J)  go  to  5;  otherv^risel^ U^and  go  to  2 

5)  The  subproject  is  simply  the  set  of  activities ,7l  > along 
with  the  events  START  and  FINISH  together  with  their  respec- 
tive predecessor  relations. 

Every  project  can  then  be  decomposed  into  a unique  set  of  sub- 
projects.  To  do  so,  pick  an  arbitrary  activity  or  event  in  the 
project  other  than  start  or  finish,  and  generate  the  unique  sub- 
project  of  which  it  is  a member  by  the  procedure  outlined  above. 
If  this  subproject  does  not  exhaust  the  netV7ork,  select  any  other 
activity  or  event  other  than  start  of  finish  not  contained  in 
the  subprobject  and  generate  its  subproject.  If  this  process  is 
continued,  the  set  of  subnetworks  will  eventually  exhaust  the 
network  thereby  providing  the  desired  decomposition. 


2)7n  ^ U ^ 

3^^ 


where  "P  . andit^  . are  the  predecessor  and 
J 3 
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2.4.21.6  Functional  Block 


2.4.21.7  Typical  Applications 


In  order  to  effectively  manage  large  projects,  it  is  neces- 
sary to  identify  any  independent  subprojects  they  may  contain. 
"Independent*'  here  means  that  the  activities  in  one  subproject 
have  no  predecessors  or  .successors  in  any  other  subproject.  Such 
subprojects  can  then  be  analyzed  separately  as  far  as  precedence 
calcuatlons  are  concerned.  They  are  tied  together  only  by  a 
common  start  and  finish  date  and  any  resource  requirements  they 
may  share.  Being  smaller  and  more  logically  concise,  their  cri- 
tical path  analysis  proceeds  quickly.  Hence,  the  critical  path 
calculations  for  the  complete  projects  can  be  performed  much  more 
quickly  by  analyzing  each  of  its  subprojects  independently. 

Although  the  scheduler  can  frequently  decompose  small  projects 
into  subprojects  by  simply  categorizing  the  activities  by  function, 
this  analysis  for  large  projects  is  at  best  tedious  and  at  worst 
unsuccessful.  This  module  provides  a simple  and  efficient  auto- 
mated procedure  for  decomposing  large  precedence  networks. 

t 

2.4.21.8  References 

Burman,  P.  J.:  'Pr>ecedence  lleiwovks  for  Project  Planning  and  Con- 
trol ^ McGraw  Hill,  London,  1972. 
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2.4.21.9  Detailed  Design 

Since  this  module  x^'ill  identify  subprojects  of  a specified  project, 


i 


I 


it  is  essential  that  the  project  to  be  decomposed  is’  the  first  (or  only) 
subnode  of  the  input  tree,  $JOBSET.  All  activities  and  events  (jobs) 
of  the  project  must  be  subnodes  of  this  first  subnode  of  $JOBSET.  The 
module  starts  by  placing  all  activities  and  events  of  the  project  except 
START  and  FINISH  into  an  unclassified  set.  As  each  job  is  grouped  into  a 
subproject,  is  is  removed  from  the  unclassified  set,  completion  of  the 
decomposition  is  signaled  when  the  unclassified  set  is  emptied.  The 
first  job  is  selected  from  the  unclassified  set  and  placed  in  the  current 
subproject.  Predecessors  and  successor  of  this  job  are  identified  and 
added  to  the  current  subproject.  This  process  is  repeated  until  no  new 
predecessors,  or  successors  are  found  and  a subproject  is  completed. 

Then  the  next  remaining  unclassified  job  is  selected  and  the  process  re- 
peated, until  the  unclassified  set  is  emptied.  The  functional  block 
diagram  serves  as  the  flow  chart  for  this  module, 

2.4,21. 1C  Interval  Variable  and  Tree  Name  Definitions 
$ADD 

$AUGMNT 
$ CURRENT 

$CURRENT_NAME  - 


Identifier  for  each  subnode  of  $AUGMENT  when  funding 
predecessors  and  successors 

Tree  containing  jobs  for  which  predecessors  and  successors 
are  identified 

Tree  containing  jobs  identified  as  belonging  to  the  current 
subproj  ect 

Single  level  tree  containing  only  the  names  of  jobs  in 
the  current  subproject 
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$ IMPLIED 


Single  level  tree  containing  names  of  predecessors  and 
successors  of  jobs  in  $AUGMENT 
$JOB  - Identifier  for  each  subnode  of  $AUGMENT  when  augmenting 

current  subproject 

$JOB_ID  ' - Identifier  of  each  subnode  of  the  project  provided  by 

input  $JOBSET 

$JOB_NAME  - Identifier  of  each  subnode  of  $IMPLIED 

$OUTPUT  - Tree  to  which  identified  subprojects  are  appended 

$PRED  - Identifier  for  each  subnode  of  predecessors 

$REMOVE  - Identifier  for  each  subnode  of  $CURRENT_NAME 

$SUCG  - Identifier  for  each  subnode  of  successors 

$UNCLASSIFIED  - Tree  consisting  of  jobs  not  associated  with  any 

\ 

subproject 

2.4.21.11  Modifications  to  Functional  Specification  and/or  Standard 
Data  Structures  Assumed 

The  project  to  be  decomposed  must  be  the  first  (or  only)  subnode  of 
the  input  tree  $JOBSET . If  more  than  one  project  is  included  in  $JOBSET, 
repeated  calls  to  this  module  must  be  made  to  decompose  each  project. 

With  "each  call,  only  the  first  project  under  $JOBSET  will  be  decomposed. 

Since  this  module  expects  both  predecessors  and  successors  to  be  named, 
the  module  PREDECESSOR_SET_INVERTER  should  be  called  prior  to  the  first 
call  to  the  module. 
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2.4.21.12  Commented  Code 


PHOJECT.DECOMPOSER I PROCEDURE ( SnETWORK  » SOECOMPOSED„NET WORK ) 

OPTIONS (EXTERNAL)  I 

/•  f ^ 

/*  PROJECT  decomposer  idfntieies  the  independent  subprojects  */ 

/*  that  are  contained  within  a large  project,  by  independent*  f/ 

/♦  WE  MEAN  that  NO  ACTIVITY  IN  ONE  SUBPROJECT  HAS  PREDECESSORS  */ 

/*  OR  SUCCESSORS  IN  ANY  OTHER  SURPROjECT.  */ 

/♦  5^ 

/♦  ALL  ACTIVITIES  AND  EVENTS  OF  THE  PROJECT  TO  BE  DECOMPOSED  */ 

/♦  MUST  be  subnodes  OF  THE  FIRST  SUBnODE  OF  THE  INPUT  SJOBSET,  #/ 

/♦  The  OUTPUT  subprojects  APE  returned  as  the  FIRST  *N*  SUBNODES.  */ 

/*  OF  SJOBSET*  Where  *n»  is  the  number  of  subprojects  identified.  ♦/ 

/•  ANY  other  projects  WILL  FOLLOW  THESE  N SUBNODES*  IF  ANY  OF  */ 

/♦  the  other  projects  ARE  Td  BE  DECOMPOSED*  IT  MUST  BE  MOVED  TO  f/ 

/*  THE  POSITION  OF  THE  FIRST  SUBNODE  AND  THIS  MODULE  CALLED  AGAIN.  */ 

/*  . _ 
DECLARE  $CURRENT*$IMPlIED*$AUgMENT**UNCLASSIFIEDoSCURRENT.NAME  local  I 
declare  SJOB*SJOR..ID*SPRED*SSuCC9SJOr1nAME*SAOD*$REMOVE»SOUTPUT * 
$NETWORK*SDECOMPOSEO«NETWORK*$TEMP_PREO*$TEMP_SUCC  LOCAL! 

/•  THE  module  starts  BY  PLACING  ALL  ACTIVITIES  AND  EVENTS  IN  »/ 

/*  A SET  TO  BE  EXAMINED.  Aj'L  ACTIVITIES  OR  EVENTS  WILL  HAVE  BEEN  */ 

/*  PLACED  IN  subnetworks  AND  CONTROL  WILL  BE  RETURNED  TO  THE  */ 

/*  calling  program  when  this  sEt  has  been  emptied.  */ 


DO  FOR  ALL  SUBNODES  OF  SNETWOrK  USING  $JOB.ID! 

IF  (LABEL (SJ0B«ID)  r»START»|  LABEL j SJOB_ID)  « »FlNISHi ) THEN! 
ELSE  SUNCLASSlFlED(NEXTi  e SJOBIiD? 

END! 

P0INT_A| 

IF  SUNCLASSIFIED  IDENTICAL  TO  SNULL  THEN  DO! 

IF  SNETWORK, start  IDENTICAL  TO  SNULL  THEN! 

ELSE  graft  insfrt  snetwork .start  Before  soutput(firsT) ! 

IF  snetwork, finish  identical  to  SNULL  THEN! 

ELSE  GRAFT  INSERT  SNETWORk.FINISH  BEFORE  SOUTPUT (NEXT) ! 
LABEL(SOUTPUT)sLABEL($NETwORK) ! 

PRUNE  SNETWORK! 

SOECOMPOSED.NETWORK  = SOUTPUT! 
prune  SOUTPUT! 

RETURN! 

END! 

else  prune  scurrenti 


/♦  start  a current  subproject  set  and  an  augmenting  set  with  #/ 

/*  the  first  of  the  set  to  be  examined,  */ 

SCURRENT(NEXT)  “ $UNCLASSIfIED(EIRST) ! 

SAU6MENT(NE;«T)  « SUNCLASSI(;-IED(FIRST)  I 
SCURRENT^NAME(NEXT)  « La8El<SUNCLASSIFIED(EIRST) ) ! 

point.bj 

/*  FIND  ALL  Unique  predecessors  and  successors  of  activities  */ 

/♦  AND  EVENTS  IN  THE  AUGMENTING  SET,  */ 

DO  FOR  ALL  SUBNODES  OF  SAUgMENT  USING  SJOB! 


00  FOR  all  subnooes  of  «job,tempoHal_relation. predecessor  using 

SPRED! 
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IF  SPRFO  element  OF  SIMPLIEO  THEN! 

ELSE  SIMPlIEO(NEXT)  « SPPFDI 

end; 

DO  FOR  ALL  SUBNODES  OF  1|J08,TEMP0RAL.RELATI0N, SUCCESSOR  USING 
SSUCCI 

IF  SSUCC  element  of  SIMPLIEO  THEN» 

ELSE  SIMPLIEO (NEXT)  * fSuCCl 

end; 

END  I 

/*  REPLACE  the  AUGMENTING  SET  WITH  THE  PREDECESSORS  AND  #/ 

/*  SUCCESSORS  JUST  FOUND  WHICH  ARE  NEITHER  START  NOR  FINISH#  #/ 

/♦  NOR  WITHIN  the  CURRENT  SUBPROJECT  SET, 

PRUNE  SAU(3MENT» 

DO  FOR  ALL  SUBNODES  OF  SIMPLIEO  USING  $JOB_NAMEI 
IF  (SJOB^NAME  »»startm  sjob'name  ■»FINISH»)THEN| 

Else  if  sjob^name  element  of  scurrent_name  then; 

ELSE  $AU6mENT(NEXT)  b SUnCLASSIFIED.# (SJOB.NAME) I 

END! 

prune  SIMPLIEO! 

/♦  IF  THE  augmenting  SET  IS  NOT  EMPTY#  ADO  IT  TO  THE  CURRENT  #/ 

/*  SUBPROJECT  SET  AND  RETURN  TO  FIND  MORE  PREDECESSORS  AND  #/ 

/*  SUCCESSORS,  ;; 

IF  saugment  ^ Identical  to  snuLl 
then  do; 

do  for  all  SUBNODES  oF  SaUGMENT  USING  SAODI 
SCURRENT(NEXT)  * SADoi 
SCURRENT.NAME(NEXT)  ■ LABEL($A0D)I 
End? 

go  to  POInT.8! 
end; 

/•  IF  THE  augmenting  SET  IS  EMPTY,  A SUBPROJECT  HAS  BEEN  •/ 

/*  identified  and  it  is  then  placed  IN  THE  OUTPUT  TREE,  ALL  */ 

/•  ACTIVITIES  and  events  OF  THIS  SUBPROJECT  ARE  REMOVED  FROM  THE  «/ 

/*  SET  TO  BE  examined*  AND  THE  PROCESS  REPEATED  UNTIL  THE  SET  TO  •/ 
/*  BE  EXAMINED  HaS  BEEN  EMPTIED. 

else  graft  SCURRENT  at  «0UTPIIT(NEXT)  I 
DO  FOR  ALL  SUBNODES  OF  SCUpRENtInAME  USING  SREMOVEI 
PRUNE  SUNCLASSIFIEO,#(SREMoVE) I 
ENnI 

prune  scurrent^name; 

GO  TO  point.a; 

END«PR0JECT_DEC0MP0SER:  END) 
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2.4.22  REDUNDANT  PREDECESSOR 
CHECKER 


2.4.22  REDUNDANT  PREDECESSOR  CHECKER 


2.4.22  REDUNDANT__PREDECESS0R_CHECKER 

2.4.22.1  Purpose  and  Scope 

Given  a technologically  ordered  set  of  activities  and 
respective  predecessor  sets,  this  module  eliminates  any 
redundant  predecessors.  A predecessor  is  said  to  he  redun- 
dant if  it. is  not  an  immediate  predecessor;  that  is,  there 
is  at  least  one  intervening  activity  between  the  predecessor 
and  its  successor.  As  an  example,  suppose  activity  A is  a 
predecessor  of  activity  B,  and  B is  a predecessor  of  activity 
C.  Then  A is  a redundant  predecessor  of  G,  while  A and  B 
are  immediate  predecessors  of  B and  C,  respectively. 

Expressing  a project  in  terms  of  a collection  of  nonre- 
dundant  predecessors  serves  two  useful  purpose:  (1)  it 

expedites  considerably  critical  path  calculations;  (2)  its 
facilities  comprehension  of  the  precedence  relations  by 
representing  the  project  in  terms  of  the  most  logically  con- 
cise precedence  network  possible. 

2.4.22.2  Modules  Called 
None 

2.4.22.3  Module  Input 

Network  definition  $JOBSET  - including  redundant  predecessors. 


i'3^ 
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, SJ0B5ET 


2.4.22.4  Module  Output 

Network  definition  $0()BSET  - technologically  ordered,'  exclud- 
ing redundant  predecessors. 

2.4.22.5  Functional  Description 

The  most  efficient  redundant  predessor  elimination  algorithm 
is  a two-phase  recursive  procedure  based  on  a technologically 
ordered  job  set. 

The  first,  or  forward  phase,  recursively  augments  the  predecessor 
sets  to  introduce  maximum  redundancy  beginning  with  the  predecessor 
set  of  the  first  element  in  the  technologically  ordered  job  set. 

The  second,  or  reverse  phase,  recursively  decrements  the  maximally 
redundant  predetessor  sets  to  secure  minimum  redundancy  beginning 
with  the  predecessor  set  of  the  last  element  in  the  technologically 
ordered  job  set.  The  major  difficulty  with  this  or  any  other 
algorithm  designed  to  eliminate  redundant  predecessors  is  the 
excessive  storage  requirements.  For  a job  set  containing  n ac- 
tivities up  to  n^/2  memory  cells  can  be  required  to  store  the 
intermediate  maximally  redundant  predecessors. 
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2.4.22.6  Functional  Block  Diagram 


REDUNDANT  PREDECESSOR  CHECKER 
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2. k. 22,1  Typical  Application 


The  module  can  be  applied  wherever  the  most  logically  concise 
precedence  network  representation  of  a project  is  desired.  This 
includes  critical  path  calculation,  automated  heuristic  schedul- 
ing, and  manual  precedenc.e  relation  analysis. 

2.4.22.8  References 

Muth,  John  F.  and  Gerald  L.  Thompson:  Industrial  Saheduling^ 

Prentice  Hall  Inc.,  Englewood  Cliffs,  New  Jersey,  1963. 
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2,4.22.9  Detailed  Design 

The  functional  block  diagram  provides  the  flowchart  for  this 
module.  The  module  takes  each  job  element,  i,  of  a given  subnet  in 
turn,  and  examines  each  predecessor,  j,  of  the  element.  It  augments 
the  predecessor  set  of  i with  the  predecessor  set  of  j.  When  all  job 
elements  have  been  examined,  the  maximally  redundant  predecessor  set 
has  been  formed.  Next  each  job  element,  i,  of  the  subnet  is  examined, 
but  in  reverse  order.  Each  predecessor,  j,  of  the  element  i is  exam- 
ined. If  a predecessor  of  j is  found  as  a predecessor  of  i,  it  is 
pruned  from  the  predecessor  set  of  i. 

2.4.22.10  Internal  Variable  and  Tree  Name  Dejinitions 

$PRECESS0R  - Pointer  first  subnode  of  PEIECESSOR  node 
^SET  “ Temporary  tree  storage  for  predecessor  names 

of  job  element  under  consideration 

2.4.22.11  Modifications  to  Functional  Sepcif ications  and/or  Standard 
Data  Structures  Assumed 

Since  only  a single  subnode  of  $J0BSET  is  examined  with  each  call 
to  this  module,  the  subnode  is  identified  as  $SUBNET  through  the  param- 
eter list. 
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2.4.25-12  COMHEMB  'CO'DE' 


RiDUNDANT^PREDECESSOR^CHECKERi  PROCEDURE (*SUBNET) 

OPTIONS (EXTERNAL) I 

DECLARE  $SET*  SSaVE*  SPREDEcESSOR  LOCAL; 

/#  foreword  pass  to  create  maximally  redundant  predecessor  set 

/♦  PICK  NEXT  UnfXAMINEO  ELEMFNTi  It  IN  TECHNOLOGICALLY  ORDERED 
/♦  JOB  SET  PR0CEDIN6  FORWARD 
DO  I ■ 1 TO  NUMBER (SSUBNET)  I 

/*  PICK  NEXT  UNCONSIDERED  ELFMENTt  Jt  IN  PREDECESSOR  SET  OF  I 
DO  J*  I TO  NUMBER (SSUBNET <1 ) .TEMPORAL^RELATION.PREDECESSOR)  I 

/♦  augment  predecessor  set  Of  I BY  predecessor  set  of  j 

DO  K « 1 TO  number (SSUBmET.W (SSUBNET ( I) .TEMPORALp.RELATlON 
.PREDECESSOR (J) ) .TEMPOpAL.RELATlON. PREDECESSOR)  I 
IF  SSUBNET. #(SSURNET(I) .TEMPORAL^RELATION 
.PREOECESSOR(J) ) . TfMPORAL«RELATION. PREDECESSOR (K) 
-•element  of  SSUBNET(I) .TEMPORAL.RELATION. PREDECESSOR 
THEN  SSUbNET(I) *TEMpORAL_RELATION.PREDECESSOR(NEXT)  * 
SSUBNET. W (SSUBNET(I) ,TEMP0RAL_RELATI0N.PREDECESS0R(J) ) 
, TEMPORAL^RELATION. predecessor (K)  I 

END  I 
END  I 
END  I 


/#  backward  PASS  To  CREATE  MINIMALLY  REDUNDANT  PREDECESSOR  SET 


*/ 


/*  PICK  NEXT  UNEXaMINED  ELEMFNTt  It  IN  TECHNOLOGICALLY  ORDERED  */ 

/♦  JOB  SET  PR0CEDIN6  BACKWARD 
DO  I a number < SSUBNET)  TO  1 By  -1  I 

PRUNE  SSET!  ^ • 

/*  PICK  NEXT  UNCONSIDERED  ELEMENTt  Jt  IN  PREDECESSOR  SET  OF  I 

DO  J = 1 TO  NUMBER(SSUBNET (I) .TEMPORAL.RELATION. PREDECESSOR)  I 
/♦  REMOVE  THOSE  ELEMENTS  FROM  PREDECESSOR  SET  OF  I THAT  ARE  IN  f/ 

/*  PREDECESSOR  SET  OF  J 

DO  K = 1 TO  nUMBER(SSUBnET.#(SSUBNET(I) .temporal^relation 
. PREDECESSOR (J)).TEMPOPAL-.RELATION. PREDECESSOR)  I 

IF  SSURNET.W(SSUrNET(I) .TEMPORAL_RELATION,PREDECESSOR(J) ) 
eTEMPORAL.RELATION. predecessor (K)  ELEMENT  OF  $SUBNET(I) 
.temporal  relation. PREIdECESSOR  & SSUBNET. W(SSUBNET(I) 
.TEMPORAlIrELATION. predecessor (J) ) .TEMPORAL.RELATION 
.PREDECESSOR(K)  - element  of  $set 
then  SSET(NEXT)  ® SsUBNET.W(SSUBNET(I) .temporai — relation 

.predecessor (J) ). TfMPORAL.RELATION. PREDECESSOR (K)  I 

end  I 

END  ! 


PRUNE  SSAVEI 

IF  SSUBNET (1) .TEMPORALIRELATION. PREDECESSOR 


IDENTICAL  TO  SNUlI’ 
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THEN  00 I 

define  SPREOECESSOr  as  SSUBNET(I) ,TEMP0RAL«RELATI0N, 
PREOECESSOR(FIRST) I 

DO  WHILE  ($PREDECE?5S0R  - IDENTICAL  TO  SNULLM 
IF  SPREOECESSOR  ELEMENT  oF  $S£T 

then  prune  spreoecessori 

ELSE  ADVANCE  $PREDECESS0RI 

end  I 

END  I 

END  I 

END  REpUNOANT«PREDECESSOR„CHErKER I 
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2.4.23  CRITICAL__PATH_CALCULATOR 
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2.4.23  CRITICAL_PATH_CALCULATOR 

2.4.23.1  Pur£Ose  and  Scope 

This  module  will  calculate  the  critical  path  data  for  a proj- 
ect network.  The  variables  computed  are:  (1)  early-start,  late- 

start,  early-f inish,  and  late-finish  of  each  activity;  (2)  early 
occurrence  and  late  occurrence  of  each  event;  and  (3)  total  slack 
and  free  slack  of  each  activity  and  event. 

A project  that  is  defined  by  a collection  of  activities  and 
events,  their  precedence  constraints,  and  their  durations  must 
meet  several  other  requirements  to  be  amendable  to  critical  patli 
analysis : 

1)  It  must  consist  of  a finUr  collection  of  well-defined  activ- 
ities and  events  (with  no  unspecified  alternatives)  which, 
when  completed,  mark  the  end  of  tlie  project. 

2)  The  activities  may  be  started  and  stopped  independently  of 
each  other  within  a given  sequence.  This  requirement  pre- 
cludes the  analysis  of  continuous  flow  processes. 

3)  The  predecessor  relationships  among  the  activities  and  events 
must  not  contain  cycles;  that  Is  there  can  be  no  predecessor 
chains  implying  that  a job  precedes  itself.  Thus  a project 
is  nonrepetitive.  It  is  essentially  a.  one-time  el  fort  such 
as  a R&D  task  or  a construction  project. 

2.4.23.2  Modules  Called 
ORDER_BY_PREDECESSORS 
FINDJ1AX 
FIND  MIN 
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JOB  INTERVAL 


I TEMPORAL _ 
' RELATION 


FINISH 


(VALUE)  (VALUE) 


Predecessor  Qsuccessor  Qearly  Qlate  (j early  O^ate  total  (j)FR 
\ A (vJuE)  (VALUE)  (VALUE)  (VALUE)  (VALUE)  (VALUE) 


(VALUE)  (VALUE)  (VALUE)  (VALUE) 
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2.4.23.5  Functional  Description 


Critical  path  analysis  is  a powerful  but  simple  technique 
for  analyzing,  planning,  scheduling,  and  controlling  complex  proj- 
ects. In  essence,  the  method  provides  a means  of  determining  (1) 
which  activities  are  "critical"  in  their  effect  upon  total  proj- 
ect duration,  and  (2)  how  to- schedule  all  activities  to  meet  mile- 
stone dates. 

Critical  path  analysis  is  based  on  the  simple  concept  of  pre- 
decessor/successor relationships  between  the  activities  and  events 
defining  the  project  network.  A brief  introduction  to  these  fun- 
damental scheduling  concepts  is  presented  below. 

Let ^ = {i,j,k,  ...}  be  a set  of  activities  and  events  that 

must  be  completed  to  finish  a project.  Let  the  symbol  "«"  denote 

the  basic  immediate  predecessor  relation.  Thus  the  notation  i<<j 

is  interpretated  to  mean  that  activity  i must  be  completed  before 

activity  j can  start.  If  s^  denotes  the  start  oj.  activity  j and 

f denotes  the  finish  of  activity  i,  then  the  relationship  i<<j 
i 

is  equivalent  to  the  standard  inequality  The  set 

{j.j<<i}  is  said  to  be  the  immediate  predecessor  set  of  activity 
or  event  i.  Similarly  the  = {j:i<<j}»  denotes  the  im- 

mediate successor  set  of  the  activity  or  event  i. 

A directed  graph  (network)  is  a useful  topological  representa- 
tion of  a project,  and  can  provide  valuable  insight  into  many 
scheduling  problems.  A summary  of  predecessor/successor  relation- 
ships in  terms  of  their  network  representation  is  given  in 
Table  2.4.23-1.  More  general  temporal  relationships  can  be  easily 
included  within  this  simple  framework  by  adding  artificial  activities 
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Table  2.4.23-1  Basic  Precedence  Relation  ship 


[1] 

[2] 

[3] 

[43 


Suppose  now  that  every  activity  in  the  project  is  started  as 
soon  as  possible,  that  is,  as  soon  as  all  of  its  predecessors 
are  finished.-  It  is  then  possible  to  calculate  the  early  start 
of  each  activity  as 

" i 

and  the  early  finish  of  activity  i is  clearly 

f®  e 
1 * "i 

where  d is  the  duration  of  the  ith  activity  (d  = 0 for  events) . 
i ^ 

Similarly,  the  late  finish  for  activity  i is  given  by 


and  the  late  start  is 
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[5] 


For  any  activity,  the  quantity 

i e .5-  .e 

S=s.-s.  = f.-f, 
i i i 1 1 

is  defined  to  be  the  total  slack.  The  set  of  critical  activities 
is  then  the  subset  of  activities  having  minimum  -total  slack. 

Another  useful  variable  is  free  slack,  . Free  slack  is 
defined  as  the  amount  by  which  an  activity  may  be  delayed  with- 
out affecting  any  other  activity.  It  is  computed  as 


[61 

jew- 


The  logic  for  the  coordination  of  these  calculations  into 
an  efficient  computational  procedure  is  given  in  the  following 
block  diagram. 
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2.4.23.6  Functional  Block  Diagram 
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2.4.23.7  Typical  Application 


This  module  is  used  to  compute  the  basic  critical-path  data 
under  the  direction  of  executive  procedures  such  as  the  CRITICAL_ 
PATH  PROCESSOR.  The  results  are  useful  in  manual  and  automatic 
heuristic  scheduling  as  well  as  in  project  control. 

2.4.23.8  Implementation  Considerations 

This  module  plays  a fundamental  role  in  any  project  manage- 
ment system.  As  a consequence,  every  effort  should  be  made  to 
ensure  the  computational  efficiency  of  the  algorithm.  For  example, 
it  may  well  prove  worthwhile  to  code  the  algorithm  in  assembly 
language  to  optimize  execution  efficiency.  Further  it  may  be  ad- 
vantageous to  distinguish  between  activities  and  events  by  some 
other  technique  than  merely  noting  the  durations  in  the  $J0BSET 
data  structure.  In  general,  the  outline  of  the  procedure  presented 
here  is  intended  only  to  specify  the  desired  results  of  the  module. 
Any  modification  to  the  suggested  implementation  that  produces 
the  same  results  more  efficiently  is  to  be  preferred.  Finally, 
it  may  be  desirable  to  split  the  module  into  three  submodules. 

The  first  would  perform  the  forward  pass  calculations  of  early 
start  and  finish.  The  second  would  execute  the  backward  pass 
computations  of  late  start  and  finish.  The  third  would  carry  out 
the  slack  calculations. 

2.4.23.9  Reference 

Kelley,  J.  E. , Jr.:  CT'tt'taat  Path  Saheduling:  Mathematiaat  BasiSj 

Operations  Research,  Volume  9,  196T. 

Muth,  John  F.  and  Gerald  L.  Thompson:  Industrial  Scheduling, 

Prentice  Hall  Inc.,  Englewood.  Cliffs,  New  Jersey,  1963. 
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2.4.23.10  Detailed  Design 

The  functional  block  dlagran  provides  the  flowchart  for  this  module. 
The  Individual  activities  and  events  (jobs)  of  the  input  subnetwork  should 
be  ordered  according  to  precedence  relations.  This  Is  accomplished  by 
calling  the  module  ORDER_BY_PREDECESSOkS . Each  activity  or  event  in  the 
ordered  subnetwork  is  considered  in  turn  and  its  early  start  and  early 
finish  times  are  calculated.  The  early  start  time  of  a job  is  equal  to 
the  latest  early  finish  time  of  its  predecessors.  When  early  start  and 
finish  times  have  been  determined,  the  activities  and  events  in  the  ordered 
subnetwork  are  considered  in  their  reverse  order.  Late  start  and  finish 
times  are  then  determined.  The  late  finish  time  of  a job  is  equal  to  the 
earliest  start  time  of  its  successors.  Also  determined  for  each  job  are 
free  and  total  slack.  Free  slack  is  the  difference  between  the  early 
finish  of  a job  and  the  earliest  start  time  of  its  successors.  Total  slack 
is  the  difference  between  the  late  start  time  and  the  early  start  time  of 
the  job. 

2.4.23.11  Internal  Variable  and  Tree  Name  Definitions 


1 

VALJIAX 

- 

maximum  of  a set  of  values,  returned 

from 

module  FIND_MAX 

5 

VAL_MIN 

- 

minimum  of  a set  of  values,  returned 

from 

module  FINDJIIN 

i 

$FREE 

- 

tree  formed  with  values  representing 

free 

slack 

\ 

for  each  successor  of  a job.  Actual 

free 

slack 

is  the  minimum  of  these  values. 
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$SUBNET  - The  input  subnet  work  after  it  has  been  techno- 

logically ordered  by  a call  to  ORDER_BY__PElEDE- 
CESSORS 

$INDICES  - Output  of  modules  FIND_MAX  and  FINDJMIN 

not  used  in  this  module 

$PRED  - Temporary  single  node  tree,  having  only  a label 

equal  to  the  name  of  a predecessor  of  the  job 
under  consideration 

$SUGC  - Temporary  single  node  tree,  having  only  a label 

equal  to  the  name  of  a successor  of  the  job 
under  consideration 

$TEMP_PRED  - Temporary  tree  containing  values  of  early  fin- 
ish times  of  the  predecessors  of  the  job  under 
consideration 

$TEM]^SUCC  - Temporary  tree  containing  values  of  late  start 
times  of  the  successors  of  the  job  under  consi- 
deration 

2„4.23.12  Modifications  to  Functional  Specifications  and/or  Standard 
Data  Structures 

Since  only  a single  subnode  of  $JOBSET  is  considered  with  each 
call  to  this  module,  the  subnode  is  identified  as  $UMORDERED_SUBNET 

( 

through  the  parameter  list.  Additional  first  level  subnodes  of  a job 
element  (second  level  of  $SUBNET,  third  level  of  $JOBSET)  are  added  as 
shown  in  the  module  output  structure.  These  subnodes  are  START  (early 
and  late),  FINISH  (early  and  late),  and  SLACK  (total  and  free). 

I 

I 
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2 . 4 . 23 . 13  Commented  Code 


CRITI CAi PATH.CALCULATOR  t PROCEDURE  < SUNOROEREO_SUBNET  f SORDERED.SUBNET ) 

■ OPTIONS(EXTERNaL) I 

DiCLARE  I#J#VAL_MAXfVAL«MlN*SpREOf*SUCC  LOCALI 

declare  STEMP  PRED*STEMP_SUCC,'SFREF*SDURATlONtSlNDICES*f»SUBNET  LOCAL  I. 

/*  ORDER  ACtTviTY  AND  EVENT  SET  ACCORDING  TO  PRECEDENCE  RELATIONS  */ 
CALL  ORDER'BY„PREDECESSORS{$UNORDEREDlsUBMETtSSUBNET) I 

/•  SELECT  NEXT  (PROCEEDING  FORWARD)  ACTIVITY  OR  EVENT  FROM  THE  */ 

/•  technologically  ordered  set 

DO  I ■ 1 TO  number (SSUBNET) I ^ . . 

/#  COMPUTE  EARLY  START  AND  EARLY  FINISH  OF  CURRENT  ACTIVITY  OR  EVEnT  #/ 
PRUNE  STEMP.PREDI 

DO  J ■ 1 TO  NUMBER(SSUBnET(I) •TEMPOrAL_RELATION,PREDECESSOR) I 
SPRED  ■ SSUBnET(I)  .TEMPoRALilRELATlON.PREOECESS^'RCJ)  I 
STEMP.PRED(NEXT)  * SSUBnET,#($PRED) .FINISH. EARLYI 
END  I 

VAL_MAX  a 0.1 

IF  $TEMP«PRE0  IDENTICAL  TO  SNUL^  THENI 

ELSE  CALL  FIND^MaX (STEMP_PRED*SlNOlCEStVAL.MAX) I 
/•  IS  current  activity  or  event  an  event  WHOSE  EARLY  OCCURRENCE  ♦/ 
/♦  TIME  IS  specified? 

IP  ssuBNETd) .START. Early  * ♦» 

THENI 

ELSE  IF  VAI MAX  < SSUBNET ( I > .START. EARLY 

THEN  VAL-MAX  « SSUBNET ( j ) .ST ART .EARLY I 
ELSE! 

SSUBNET(l) .START. early  « VAL.MAXI 

SSUBNET ( I ) .FINISH.EARLY  » VAl — MAX  ♦ SSUBNET (I ) .DURATION! 

/#  are  there  any  ACTIVITIES  fiR  EVENTS  WITH  UNCOMPUTED  EARLY  START  */ 
/♦  AND  finish  dates  IN  TECHNOLOGICALLY  ORDERED  SET? 


END  I 

/• 

DO  I 

/* 


SELECT  NEXT  (PROCEEDING  BACKWARD)  ACTIVITY  OR  EVENT  FROM  THE 
technologically  ordered  SpT 
a number  (SSUBNET)  TOlBy-U 

COMPUTE  late  finish  AND  LaTE  START  OF  CURRENT  ACTIVITY  OR  EVENT 
PRUNE  STEMp'sUCCI  „ ^ 

DO  J « 1 TO  nUMBER(SSUBmET(J) .TEMPOoAL«RELATION. SUCCESSOR) I 
SSUCC  « SSUBnET(I) .TEMPnRAL_RELATlON.SUCCESSOR(J) I 
STEMP  SUCC (NEXT)  » $SUBnET.#($SUCC) .START .LATE I 
SFREeTj)  » SSUBNET. #($SUCC) .START*EARlY  - SSUBNET ( I ) . 

FINISH. EaRLYi 


#/ 

*/ 

♦ / 


/#  IS  current  activity  or  EVfNT  an  event  whose  late  OCCURRENCE  time  «/ 
/♦  IS  specified? 


IF  STEMP.SUCC  identical  TO  SNULL 

THEN  IF  ssubnet(I). Finish. LATE  * »» 

THEN  ssubnet(I) .Finish. LATE  » ssubnet(I) .finish. earlyi 
ELSE! 

ELSE  DO! 

CALL  FIND_MIN(STEMP_SUCC*SINDICES*VAL-MIN) I 

IF  ( ssubneT(I) .Finish. LATE  * •*  i val-min  < ssubnet(I). 
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FINISH. late  ) 

THEN  SSUBNETdi  .FINISH. late  = VAL-MINl 
ELSE! 

END? 

SSUBNET(I) .START.LATE  = SSUBNET ( I ) .E INISH.LATE  - $SUBNET(I). 

duration?  ^ ^ . 

DO  J « 1 TO  NUMBER(SSu0NET(1) .TEMPORAL^RELATION.SUCCESSOR) ? 
SSUCC  » SSUBNET(I) .TEMPORALIrELATION.SUCCESSOR(J) ? 

SFREE(J>  « SSUBNET. #(SSuCC).START.EARLY  - SSUBNETd). 

FINISH. Early? 

END? 

/*  COMPUTE  total  AND  FREE  SLACK  FOR  CURRENT  ACTIVITY  •/ 

IF  SSUCC  a ••Then  spree (FtrsT}  *^o? 

CALL  FIND«MIN(SFREE*SlNDlcES*VAL_MlN) ? 

SSUBNET (I). SLACK. Free  a VAL.MTN? 

SSUBNET ( I) .SLACK.TOTAL  » 5SUBmET<I) .START.LaTE  - SSUBNETd) .start. 
EARLY? 

/#  ARE  THERE  ANY  ACTIVITIES  oR  EVENTS  WITH  UNCOMPUTED  LATE  START  «/ 
/♦  AND  finish  dates  IN  TECHNOLOGICALLY  ORDERED  SET?  */ 

END? 

SORDEREO.SUBNET  « SSUBNETJ 

end?  /*  CRlTlCAL_PATH.CAi  CULATOR  */ 
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2.4.24  PREDECESSOR  SET  INVERTER 


2.4.24  PREDECESSOR_SET_INVERTER 


2.4.2A  PREUECESS0R_SET_IMVERTER 

2.4.24.1  Purpose  and  Scope 

Given  a set  of  activities  and  their  respective  predecessor 
setS)  this  module  will  form  the  respective  successor  sets.  This 
inversion  process  is  necessary  for  critical  path  computation.  The 
project  scheduling  system  assumes  throughout  that  stating  precedence 
relations  in  terms  of  predecessor  sets  is  more  natural  than  ex- 
pressing them  as  successor  sets.  For  this  reason  the  user  is  asked 
to  define  all  subnetwork  topology  in  terms  of  predcccasor  sets  in 
the  input  data  structure  $J0BSET . 

2.4.24.2  Modules  Called 


None 


2.4.24.3  Module  Input 

Network  definition  ($J0BSET)-  The  substructures  of  the  tree 
beginning  at  the  nodes  labeled  SUCCESSORS  are  null  upon  input  to 

the  module. 


$00BSET 


(JOB  ID) 
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2.4.24.4  Module  Output 

Redundant  network  definition  ($J0BSET)  - The  substructures  of 
the  tree  beginning  at  the  nodes  labeled  SUCCESSORS  are  complete 
upon  exit  from  the  module. 


$J0BSET 
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2.4.24.5  Functional  Description 

The  logic  of  the  inversion  process  from  predecessor  sets  is 
simple  and  direct.  Each  activity  in  the  job  set  is  considered 
in  turn.  Whenever  a given  activity  is  found  in  the  predecessor 
set  of  another,  the  latter  is  included  in  the  successor  set  of 
the  former.  When  all  of  the  predecessor  sets  of  all  of  the  jobs 
have  been  examined,  the  collection  of  successor  sets  is  complete 
The  following  block  diagram  illustrates  this  straightforward  yet 
efficient  logic. 
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2.4.24-7  Typical  Application 

The  module  can  be  applied  wherever  successor  sets  rather  than 
user  input  predecessor  sets  are  required.  This  includes  the  mod- 
ules CRITICAL_PATH_CALCULATOR. 
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2.4o24o8  Detailed  Design 


The  functional  block  diagram  provides  the  flow  chart  for  this 
module.  The  module  loops  on  subnet  - i.e,,  job  name,  and  predecessors. 
For  each  predecessor  job,  the  name  of  the  current  job  is  inserted  as  a 


successor. 

2.4.24.9  Internal  Variable  and  Tree  Names 

$JOB__ID  - Identifier  for  each  subnode  of  $SUBNET 

$SUBNET  - Identifier  for  each  subnode  of  $JOBSET 

$TEMP_PRED  ” Identifier  for  each  subnode  of  PREDECESSOR  node 

2.4.24.10  Modifications  to  Functional  Specifications,  and/or  Standard 
Data  Structures  Assume 


None 


2.4.24.11  Commented  Code 


PREDECESS0R«SET_INVERTER*  procedure (SJOBSET) 

OPTIONS(EXTERNaL) » 

declare  SSU8NET,*J0B.ID**TEMPWPRED  LOCALI 
DO  FOR  ALL  SUBNODES  OF  SJORSET  USING  SSUBnETI 
DO  FOR  ALL  SURNOOES  OF  SSUrNET  USING  SJOB.IDI 

DO  FOR  all  subnooes  OF  f jobbid.temporal«relation.predecessor 
USING  «temp_predi 

IF  LABEL (SJOB.ID)  -ELEMENT  OF  SSUBNET,# (STEMP.PREO) • 

temporal.relaTion, SUCCESSOR  then 
$SUBNET.#($TEMP1pRED) ,TfMP0RAL1rELATI0N,SUCCESSCR(NEXT)  ■ 
label  <$uobj:IO)  I 

end  I 

END  I 
ENDI 

END!  /*  PREDECESSOR_SET«INVfRTER  */ 
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2.4.25  NETWORK^CONDENSER 


2.4.25  NETWORK  CONDENSER 


2.4.25  NETWORK_CONDENSER 

2.4.25.1  Purpose  and  Scope 

Condensing  a network  is  the  process  of  eliminating  actxvitxes 
from  the  network  leaving  only  events,  as  nodes,  linked  by  delays, 
as  branches.  These  delays  are  simply  the  maximum  sum  of  actxvxty 
durations  along  any  path  leading  directly  from  one  event  to  an- 
other. Condensation  is  useful  in  two  contexts:  (1)  integrating 

subnetworks  into  master  networks  and  (2)  summarizxng  networks  for 
management  review.  This  module  will  perform  such  a condensatxon 
on  a specified  network. 

The  condensed  event  node  network  can  be  defined  precxsely  xn 
terms  of  the  original  network  from  which  it  is  derived.  The  con- 
densed network  contains,  as  nodes,  precisely  those  nodes  that 
were  events  in  the  original  network.  A pair  of  nodes  xs  Ixnked 
by  a branch  wherever  there  is  possible  path  in  the  original  net- 
tTOrk  between  the  respective  events,  which  does  not  contaxn  any 
other  event.  A critical  delay,  defined  to  be  the  longest  path 
in  the  original  network  between  the  two  events  and  passing  through 
no  third  event,  is  assigned  to  each  such  branch  in  the  condensed 

network. 
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The  availability  of  this  critical  delay  figure  between  any 
two  connected  events  facilitates  the  merging  of  subnetworks  into 
a master  network.  This  integration  facility  is  essential  for  any 
practical  multilevel  project  analysis.  The  condensed  version  of 
any  two  networks  having  interfaces  events  can  be  merged  together 
into  a composite  condensed  network'  as  follows.  For  each  pair  of 
interface -nodes,  which  are  linked  in  both  condensed  subnetworks, 
replace  the  critical  delay  on  the  resulting  branch  in  the  condensed 
composite  network  by  the  maximum  of  the  respective  values  for  the 
subnetworks.  All  other  branches  and  critical  dealys  in  either 
of  the  two  condensed  subnetworks  are  simply  transcribed  into  the 
composite  condensed  network. 

The  critical  path  data  can  then  be  readily  calculated  from 
the  composite  condensed  network.  Each  of  the  branches  is  treated 
as  an  activity  with  a duration  equal  to  its  critical  delay.  The 
early  and  late  occurrence  dates  and  the  free  and  total  float  of 
each  event  can  then  be  computed  in  the  usual  manner.  Once  critical 
path  data  for  the  events  in  the  master  condensed  network  have  been 
calculated,  they  can  be  substituted  back  into  the  original  sub- 
networks to  determine  the  corresponding  data  for  the  original 
activities. 

Thus,  the  condensation  and  merging  processes  make  it  possible 
to  logically  segment  a project  into  tractable  subnetworks  of  suc- 
cessively higher  levels  of  detail  so  that  the  entire  project,  no 
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matter  what  its  size,  can  be  viewed  as  one  comprehensible  sum 
marized  network.  Without  this  capability  network  analysis  would 

be  of  little  value  to  project  scheduling. 

The  purpose  of  this  module*  is  then  to  convert  a network,  spec- 
ified in  terms  of  a jobset  with  its  corresponding  family  of  pre- 
decessor sets  and  durations,  into  a condensed  network  defined  by 
its  event  and  pseudo-activity  set  with  its  corresponding  collection 
of  predecessor  sets  and  durations. 

2.4.25.2  Modules  Called 
None 
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2.4.25.3  Module  Input 


Critical  Path  Input  Data  ($J0BSET) 


SJOBSET 


(JOB  ID) 
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2.4.25.4  Module  Output 


Tree  Defining  the  Condensed  network 


$CONDENSED«JOBSET 


2.4.25.5  Functional  Description 

The  problero  of  finding  the  critical  delay  between  any  pair 
of  events  is  simply  that  of  finding  the  longest  directed  path  be- 
tween two  nodes  in  a network  not  passing  through  any  third  node. 
Because  the  critical  delays  between  all  directly  connected  events 
are  desired,  the  following  approach  suggests  itself.  Consider 
each  event  in  turn.  Step  by  step,  examine  all  possible  paths 
that  terminate  at  the  current  event  under  analysis.  All  branches 
of  any  path  must  be  investigated  and  for  this  reason  a "pushdown” 
stack  is  useful  in  recalling  wnich  alternatives  remain  unexamined. 
A path  is  eliminated  from  further  consideration  when  it  reaches 
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an  event  or  merges  with  some  other  path  of  greater  length.  Since 
the  topology  of  the  condensed  networks  are  specified  in  terms  of 
precedence  sets  rather  than  successor  sets,  it  is  convenient  to 
proceed  along  the  activity  paths  in  reverse  order  to  activity 
performance. 

The  macrologic  of  the  module  requires  a few  further  words  of 
explanation.  First,  when  an  event  is  transferred  from  the  input 
tree  $J0BSET  to  the  output  tree  $CONDENSED_JOBSET , its  predeces- 
sors are  omitted  and  its  duration  is  maintained  at  zero.  Second, 
when  candidate  early  start  and  finish  times  are  computed,  the 
calculations  are  performed  as  though  the  activities  and  events 
proceeded  backward  in  time.  This  point  of  view  is  adopted  to 
avoid  the  costly  process  of  inverting  the  predecessor  sets  to 
obtain  successor  sets.  Finally,  the  details  of  inserting  a 
pseudo-activity  into  the  output  tree  $CONDENSED_JOBSET  are  des- 
cribed. If  pseudo-activity  1 represents  a critical  delay  orig- 
inating at  event  i and  terminating  at  event  j,  then  the  pseudo- 
activity should  be  listed  as  a predecessor  of  event  j and  event 
i should  be  listed  as  a predecessor  of  pseudo-activity  /.  The 
duration  of  the  pseudo-activity  is  simply  the  critical  delay  be- 
tween events  i and  j (that  is,  the  early  start  of  event  i computed 
with  respect  to  event  j). 
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2,4.25.6  Functional  Block  Diagram 
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c 


Pick  next  element 
of  discovered  event 
record  j 


Add  activity  i to  $CONDENSED_JOBSET 

with  duration  equal  to  "early  finish" 
of  event  j 

Make  j the  predecessor  of  I 

Add  £ to  predecessor  net  of 
saved  element  i 
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2.4.25.7  Typical  Application 


Network  condensation  has  two  basic  applications.  The  first 
and  most  important  is  to  facilitate  Integration  of  subnetworks 
into  master  networks.  Condensed  subnetworks- with  complex  inter- 
facing events  can  be  merged  into  a simple  composite  condensed 
network  equivalent  to  the  complete  composite  network  for  critical 
path  calculations  concerning  events.  The  condensed  composite 
network  is  substantially  smaller  in  terms  of  node  and  branch 
counts  making  critical  path  analysis  feasible  in  high-speed  mem- 
ory. The  complete  composite  network,  on  the  other  hand,  is  fre-  - 
quently  too  large  to  permit  analysis  without  the  use  of  slower 
mass  storage.  Furthermore,  the  relative  execution  times  of  small 
and  large  networks  are  such  that  critical  path  data  can  be  gen- 
erated more  rapidly  by  treating  a condensed  master  network  and 
using  the  resulting  event  early  occurrence  times  to  solve  the 
complete  subnetworks  than  by  directly  solving  the  complete  master 
network. 

The  second  use  of  network  condensation  is  in  summarizing  a 
complex  network  for  top-level  review.  The  webs  of  jobs  connect- 
ing milestone  events  are  replaced  by  simple  sets  of  pseudo-jobs — 
one  for  each  direct  path  between  any  two  events.  Thus,  the  crit- 
icality of  the  respective  events  as  well  as  their  interdependence 
is  made  more  transparent. 

2.4.25.8  References 

Burman,  P.  J.,  Preoedenae  Networks  for  Project  Planning  and  Con- 
troli  McGraw  Hill,  London,  1972.  . 
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2.4.25.9  Detailed  Design 


The  functional  block  diagram  provides  the  flov?  chart  for  this 
module.  The  module  first  examines  each  job  element  to  determine 
whether  the  element  is  an  activity  or  an  event.  An  event  has  a dur- 
ation of  zero.  Each  event  of  the  subnetwork  is  placed  in  the  tree 
$GONDENSED_JOBSET,  without  transferring  its  predecessors.  The  early 
"finish"  times  of  all  activities  and  events  are  initialized  to  zero. 
The  next  event,  i,  is  selected  from  $CONDENSED_JOBSET  for  analysis 
and  its  label  is  placed  in  the  stack.  Each  predecessor  of  event  i 
is  used  to  call  the  recursive  procedure,  CHECK__DURA,  in  order  to  de- 
velop the  critical  delay  to  this  event.  The  duration  of  the  prede- 
cessor is  added  to  the  early  "finish"  of  the  event,  and  this  value 
is  compared  with  the  early  "finish"  of  the  predecessor.  If  the  cal- 
culated early  "finish"  time  is  greater  than  that  of  the  predecessor, 
it  replaces  that  of  the  predecessor.  If  the  predecessor  is  an  event 
(duration  equal  to  zero)  it  is  added  to  the  stack  of  discovered 
events,  otherwise,  it  is  added  to  the  stack  to  be  examined.  If  the 
current  predecessor  has  predecessors,  each  in  turn  is  used  to  call 
the  recursive  procedure.  When  the  stack  to  be  examined  is  finally 
emptied,  i.e,  all  jobs  have  been  examined,  the  substructure  of 
$CONDENSED_JOBSET  is  completed, 

2.4.25,10  Internal  Variable  and  Tree  Name  Definitions 

DXJRA  - Duration  of  the  correct  predecessor  being 

examined  in  CHECK__DURA,  to  simplify  calling 

EARLY  FINISH  - Value  of  early  finish  of  event  under  exam- 

ination plus  duration  of  its  current  pred- 
ecessor 
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$DISCOVEEED_EVENT  - 
$JOB 

$JOB__NAME 

L 

$NEXT__EVENT 

$PRED 

$PEIED_NAME 

$SAVE__ELEMENT 

$STACK 


Stack  of  events  discovered  in  checking 
predecessors. 

Identifier  for  each  subnode  of  $SUBNET 

Identifier  for  each  subnode  of  $CONDENSED__ 
SUBNET 

Counter  used  as  the  label  for  the  identi- 
fied delays 

Identifier  for  each  subnode  of  $DISCOVERED_ 
EVENT 

Identifier  for  each  subnode  of  the  PREDECES 
SOR  node 

Name  of  the  events  predecessor  used  in  the 
recursive  procedure  CHECK__DURA 

Name  of  current  event  under  examination 

List  of  jobs  to  be  examined 


2.4.25,11  Modification  to  Functional  Specifications  and/or  Standa^ 
Data  Structures  Assumed 

Since  only  one  subnetwork  is  used  to  call  this  module,  $SUBNET 
is  the  name  used  in  the  parameter  list  of  the  module.  In  order  to 
maintain  unique  labels  for  the  identified  delays,  the  counter,  L,  is 


now  an  input  parameter 
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2.4.25.12  Commented  Code 


NITWORK  CONOENSERI  procedure (LtSSUBNETfSCONDENSED.SUBNET) 

OPTIONS(EXTERNAL) I 

DECLARE  Lf JJOB*SJOB.NAME*SSTACK*SSAVE_ELEmENT*$PREO  LOCAL! 
DECLARE  SDISCOVERED.EVENT  LOCAL! 

/•  TRANSFER  EACH  EVENT  IN  SJOBSET  TO  SCONDENSED^JOBSET  WITHOUT 

/•  transferring  predecessors 

DO  FOR  ALL  SUBNODES  OF  SSUBNEt  USING  $jOB! 

IF  SJoB. DURATION  IDENTICAL  TO  SNULL 

then  if  $JOB.JOB_INTERVaL  identical  to  SNULL 

^^^WRITE  iNEITHER_DUpATI0n1N0R-J0B_INTERVAL.INPUT» ! 

WRITE  label ( SSUBNFT ) ! 

WRITE  label (SJOB)! 

RETURN! 

END! 

ELSE  SJOB.DURATION  » SJOB. JOBl^INTERVAL. END  - SJOP. 
JObIiNTERVAL. START! 

ELSE! 

IF  SJOB.DURATION  ■ 0 THEN  DO! 

LABEL (SCONDENSEdIsUBNET (NEXT) ) » LABEL (SJOB)! 
SCONDENSEO^SUBNET (LAST) .duration  = SJOB.DURATION! 

END! 

ELSE! 

Oo'^FOR  ALL  SUBNODES  OF  SCONDEmSED^SUBNET  USING  SJOB^NAME! 

/*  INITIALIZE  early  FINISH  TIMES  OF  ALL  JOBS  TO  ZERO 
DO  FOR  ALL  SUBNODES  OF  SSUbNET  USING  SJOB! 

SJOB.EARLY-.FINISH  * 0! 

END! 

prune  SDISCOVERED-EVENT! 

insert  label (SJ0B«NAME>  before  SSTACK(FIRST) ! 

SSAVE.ELEMENT  * SSTACK (FIRST) t 


*/ 


*> 


POINT^B: 

/*  PICK  NFXT  PREDECESSOR  ACTIVITY*  K „ • 

DO  FOR  ALL  SUBNqDES  OF  SSUrneT.# (SSTACK (FIRST) ) .TEMPORAL^RELATION 
predecessor  using  SPpED! 

/•  COMPUTE  candidate  *early  finish*  time  for  activity*  k 

CALL  GHECK«DURA($PREO) ! 


♦ / 

. 


/• 

/* 


/* 


CHECK  DURA*  PROCEDURE  (SPREOlNAMp  RECURSIVE! 

declare  dura.  EARLYiFINlSH;$NEXT_EyENT,SPRED_NAME*$TEMP_PRED  LOCAH 
DURA  a SSUBNET.#  (SPREDJ^AMp)  .DURATION! 

early  FINISH  « sSUBNET.#(SSTACK (FIRST) ) .EARLY.FINISH  ♦ DURA! 

IS  candidate  *early  finish*  time  greater  than  current  *EARLY 
riNISH*  time  for  activity  k?  , , ^ 

IF  EARLY_FINISH  > SSUBNET.# (SPRF0_NAME) .EARLY^FINISH 

replace'^current  »^EARLY  finish*  time  of  activity  k by  candidate 

SSUBNET.# (SPRED.NAME) .EARLY^FINISH  = EARLY.FINISH! 

IS  K AN  EVENT? 

IF  DURA  * 0 


*/ 

*> 


*/ 


*/ 
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/•  ADD  K TO  DISCOVERED  EVENT  RECORD  *.,crm,crocn  fwfnt 

THEN  IF  SRRED.NAME  NOT  ELEMENT  OF  $OISCOVERED_EVENT 

^”^sdiscovered|event(nexT)  s SPRED^NAMEI 
GO  TO  POlNTiBI 

end? 

ELSE  I 

^^^INSERT  SPREO^NaME  before  SSTACK(FIRST) I 
60  TO  POINT^BI 
END! 

END  I 

elsei 

end I /*  CHeGK^DURA  */ 

ENDI 

/*  REMOVE  TOP  element  FROM  STaCK 
PRUNE  SSTACK(FIRST) I 
IF  SSTaCK  identical  TO  SNUL»- 

/♦  PICK  NEXT  element  OF  OlSCpVEREO  ^^ENT  RECORD  J USiNr 

THEN  DO  FOR  ALL  SUBNODES  OF  SDISCOVEREO.EVENT  USING 

/*  ADO  activity  l to*scondensed*jobset  with  duration  equal  to 

/#  tEARLY  FINISH*  OF  EVENT  J ^ i. 

LABEL  (SC0N0FNSED_SUBNET  (NEXT) ) “ , 

SCONDENSED.SUBNET (LAST) .DURATION  = SSUBNET. 

#(5NExT1EVFNT) .early^finishi 

/.  MAKE  J THE 

(NEXT)  » SNEXtLEVENTI 

/.  ADO  L TO  predecessor^set  , js^ve.elementi .temporal-RelSt ION. 

predecessor (NEXT)  * LI 
L * L ♦ n 
ENDI 

ELSE  60  TO  POInT^BI 


*/ 


*/ 


*/ 
♦ / 


*/ 


OO^^FOR  ALL  SUBNOOES  OF  SSUBNET  USING  SjOBI 

PRUNE  sjob.earlyIfinishi 
IF  SJ08, jobIinterval  -.  identical  to  snull 
then  prune  SJOB.DURATIONI 

ENDI  NETWORK.CONDENSER  */ 
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2.4.26  CONDENSED_NETWORK 
MERGER 


2.4.26  CONDENSED_NETWORK_MERGER 

2.4.26.1  Purpose  and  Scope 

This  module  will  merge  two  condensed  subnetworks  into  a com- 
posite condensed  network.  This  process  is  essential  in  merging 
subnetworks  into  a self-contained  master  network. 

2.4.26.2  Modules  Called 
SET_INTEP  ACTION 
SETJINION 

NETWORK  CONDENSER 
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2.4.26.3  Module  Input 


Critical  path  data  for  condensed  subnetwork  and  condensed 
master  subnetworks  $CONDENSED_JOBSET 


$CONDENSED_jJOBSET 


2.4.26.4  Module  Output 

Critical  path  input  data  for  merged  network  contained  under 
master  subnetworks  node  of  $CONDENSED  JOBSET. 
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2.4.26.5  Functional  Description 


The  object  of  this  module  although  specialized  is  critical 
to  effective  critical  path  analysis  by  subnetworks.  By  applying 
this  module  in  conjunction  with  the  NETWORK_CONDENSER  module, 
the  CRITICAL_PATH_PROCESSOR  is  able  to  assemble  a self-contained 

condensed  network.  By  applying  the  CRITICAL PATH_CALCULATOR  to 

the  resulting  network  the  critical-path  data  on  the  interfacing 
events  is  obtained.  These  data  are  then  substituted  back  into 
the  original  subnetworks  to  obtain  the  critical  path  figures  for 
their  respective  activities. 

What  is  required  of  the  merging  routine  in  the  context  of 
the  CRITICAL_PATH_PROCESSOR  is  the  capability  of  combining  two 
critical  path  input  data  structures  for  two  condensed  networks 
to  yield  a resultant  structure  representing  the  composite  con- 
densed network.  The  rules  for  performing  the  merger  follow  di- 
rectly from  the  definition  of  a condensed  network.  Recall  that 
a condensed  network  consists  of  all  of  the  events  of  the  original 
network  connected  by  activities  representing  critical  delays. 

Two  events  are  connected  by  such  an  activity  when  there  is  at 
least  one  path  between  them  in  the  original  network  that  contains 
no  third  event.  The  durations  along  all  paths  directly  connecting 
the  two  activities.  The  rules  for  merging  two  condensed  networks 
are  as  follows ; 

1)  Merge  events.  Let  denote  the  set  of  events  in  condensed 

network  N..  Then  if  N,  and  N,  are  the  condensed  networks  to 
1 j k 

be  merged  the  event  set  E of  the  merged  network  is  simply 


E = E.UE, 
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2)  Merge  Pseudo-Activities.  Let  and  be  two  interface 
events  common  to  both  N.  and  N , then  the  delay  between 
these  events  in  the  merged  network  is  calculated  as 


d /e  , 

e ^ 

1 = max 

Id. 

/e  , e \ , d /e  , e \ 

1 ™ 

! 2 

1 m n|  k m n/ 

where 

d.  1 
1 ' 

^e  , e \ 
^ m nj 

is 

the  delay  calculate 

The  remaining  pseudo-activities  defining  the  delay  between 
non- interfacing  events  can  be  added  directly  to  the  merged 
network. 
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2.4.26.6  Functional  Block  Diagram 
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In  activity/event  tree 
of  network  being  augmented 
set  the  duration  of  the 
activity  to  the  maximum 
of  the  values  found  in 
the  two  networks  to  be 
merged . 


2.4.26.7  Typical  Applications 

The  sole  application  of  this  module  is  in  the  recursive  con- 
struction of  a master  network  from  a specified  master  subnetwork 
and  all  of  its  interfacing  subnetworks  as  directed  by  the  exec- 
utive procedure  CRITICAL_PATH_PROCESSOR  and  supported  by  the  pro- 
cedure NETWORK_CONDENSER. 

2.4.26.8  Reference 

Burman,  P.  J.,  FTeoedence  Networks  for  Projeot  Planning  and 
Control^  McGraw  Hill,  London,  1972. 

IBM,  Project  Management  System  IV,  Network  Processor  Program 
Description  and  Operations  Manual^  Publication  SH20— 0899— 1,  1972. 
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2.4.26.9  Detailed  Design 


The  functional  block  diagram  may  be  used  as  a flow  chart  for  this 
module.  Since  one  condensed  network  is  to  be  merged  with  another,  it  is 
desirable  that  the  resulting  network  have  the  same  name  as  one  of  the  initial 
two.  In  this  case  B will  be  merged  into  A,  and  returned,  as  A.  In  order  to 
preserve  the  initial  A for  operations,  it  will  be  duplicated  as  C and  C will 
be  used  to  build  the  merged  network.  Each  job  of  network  B is  examined.  If 
the  job  is  an  event  and  is  not  included  in  network  A,  the  event  is  added  to 
network  C,  otherwise  the  predecessor  set  of  A is  augmented  by  the  predecessor 
set  of  B and  placed  in  C.  If  the  job  is  an  activity  and  is  a critical  delay 
between  events  of  A,  the  greater  duration  of  the  activity  is  included  in  C. 

If  the  activity  is  not  a critical  delay  in  A,  the  activity  is  added  to  C. 
When  all  jobs  of  B have  been  examined,  network  A is  replaced  by  network  C, 
the  merged  network. 

2.4.26.10  Internal  Variable  and  Tree  Name  Definitions 

$NA1'IE  A - tree  whose  single  level  substructure  contains  the  labels  of  the 
jobs  in  network  A. 

$NAME  B - tree  whose  single  level  substructure  contains  the  labels  of  the 


jobs  in  network  B. 

$PRED  - temporary  storage  for  a predecessor  name,  for  ease  in  referencing. 

$SUGC  - temporary  storage  for  a successor  name,  for  ease  in  referencing. 


2.4.26.11  Modifications  to  Functional  Specifications  and/or  Standard  Data 


Structures  Assumed 

The  subnetworks  A and  B of  $J0BSET  are  identified  as  $SUBNET_A  and 
$SUBNET  B in  the  calling  parameter  list. 


i 

I 

i 

I 

I 
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2. A. 26. 12  Commented  Code 


C6N0ENSE0«NETW0RK_MERGER  t procedure ( $SUBNET_A  » SSUBNET.B ) 

options (EXTERNAL)  I 


declare  number^delay  locali 
DECLARE  SSUBNETlo  LOCaU 

DECLARE  $NAME«Af $NAME_B*SPRED*$SUcC#$SUBNET_C  LOCALI 
declare  I,J#$INTERsECTf$UNION,$B  LOCALI 


DO 


DO 


$SUBNET„C  a SSUBNET^I 

do  I » 1 TO  number (SSUBNET^A) I 

SNAME^Ad)  = LABEL($SUBNETt  Adi  ) I 
END! 

I = 1 TO  number (SSUBNET^B) I 
SNAME.Bd)  = LABEL($SUBNET|B(I)  ) I 
ENDI 

I s 1 TO  number (SNAME.B) I 
IE  ssubnet.b d) .duration  Identical  to  snull 

Then  if  ssubnetIb(i) .jor_intervaL  identical  to  snull 

THEN  DOI 

WRITE  »neither_duration_nor-Job„interval„input*  * 
label (SSUBNET.B) • label (SSU8NET_B(I) ) I 
RE  TURN I 

ENDl  ^ ^ 

else  SSUBNET  B (I). duration  “ SSUBNET.Bd) •JOB^INTERVAL.END 
- SSUBNET.B ( I ) .JOB.INTERVAL. START  I 


elsei 

IF  SSUBNET.^8  (I ) .duration  = 0 

then  doi 
prune  SB  I 

SR (FIRST)  * $NAME^B(I)|  ^ 

CALL  SETlNTERSECTlON(SB*SNAMEiflA9$lNTERSECT)  I 

IF  SINTERSECT  IDENTICAL  TO  SNULL 

THEN  $SUBNET.C(NEXT)  a SSUBNET^Bd)? 
else  DOI 

CALL  SETUNI0N(SSUBNET_B (I ) • TEMPORAL„RELATlON. 

PRE0ECESS0R'3SUBNET_A8#(SNAME_B(I) ) e 
TEMPORAL„REL‘aTION.PR^DECESSOR*'!^UNION)  I 
GRAFT  SUNION  At  SSUBNET^C .# ( SNAME^B ( I ) ) . 

temporal^rel  ation, predecessor  I 

ENDl 


else  do  for  all  subnodes  of  SSUBNET_B(I) .temporal^relation. 
PREDECESSOR  USING  SPREDI 
DO  J * 1 TO  number (SSUBNET.B) ? 

IF  SNAME^d)  element  OF  SSUBNET.,B  ( J)  .TEMP0RAL_RELATI0N.  ^ 

PREDECESSOR 

THEN  SSUCC  = LABEL(SSUBNEt|B(J) ) I 
ENDl  ...  , . . 

IF  (SPREO  ELEMENT  OF  SSUBNET.A^^ dNAME_B d ) ) .TEMPORAL^RELaTION 
.PREDECESSOR  ^ SNaME„B(!)  ELEmENT  OF  SSUBNET.A.# ( SSuCC) • 

TEMP0RAL...RELATI0N«PRE0ECESS0R)  _ . _ 
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THEN  IF  SSUBNET«B( I) .DURATION  > SSUBNET^A.# ($NAME«B ( I ) ) . 
duration  then  *SUBNET-C(NEXT)  « SSUBNET^Bdj  I 
ELSE  $SUBNET«C(NEXT)  » sSUBNETIa.# (SNAME.B ( 1 ) ) I 
else  SSUBNET_C(NEXT)  > SSUBNET.Bd)  I 

END! 

END  I 

NUMBER.DELAY  ■ 11 

CXLL  NETWORK_CONOENSER(NUMBER%ELAY#SSUBNET_CfSSUBNET.D)  I 
GRAFT  SSUBNET.D  AT  SSuBNET^aT' 

END I /*  condensedInetworkshergfr  */ 
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2.4.27  NETWORK  ASSEMBLER 


‘2.4.27  NETWORK_AS  SEMBLER 

2.4.27.1  Purpose  and  Scope 

Given  a master  subnetwork  and  its  prescribed  interfacing 
events,  this  module  will  assemble  this  subnetwork  and  all  of 
its  interfacing  subnetworks  into  a master  network.  This 
assembly  capability  facilitates  the  heuristic  scheduling  of 
any  combination  of  subnetworks  that  may  share  common  resources 
The  list  of  interfacing  events  need  only  be  constructed  to 
draw  together  all  of  the  desired  subnetworks. 

2.4.27.2  Modules  Called 
REDUNDANT_PREDECE SSOR_CHECKER 
SET_INTERSECTION 
SETJINION 

2.4.27.3  Module  Input 

1)  Master  subnetwork  identifier  ($MA.STER_SUBNET__ID) 
$MA.STER_SUBNET__ID 

0 

(SUBNET  ID) 


2)  Interface  event 


definition  ($INTERFACE) 


$INTERFACE 


(IDENTIFIER  OF 
CONTAINING  SUBNET) 


3)  Subnetwork  definitions,  including  master  subnetwork  ($J0BSET) 


tJOeSET 
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2.4.27.4  Module  Output 


1)  Heuristic  processor  input  data  under  master  subnetwork  node 

of  $J0BSET 

2)  Component  Subnetworks  of  Master  Network  ($SUBNET_SET) 

A.  Component  subnet  identifier 


$SUBNET_SET 


The  assembly  of  the  master  subnetwork  and  all  of  its  inter- 
facing subnetworks  into  a master  network  is  straightforward.  A 
"pushdown"  stack  of  interfacing  subnetworks  to  be  examined  is 
initialized  to  contain  the  master  subnetwork.  The  top  element 
of  the  stack  is  analyzed  for  interfacing  subnetworks  by  succes- 
sively examining  each  of  its  events  for  their  presence  in  other 
unexamined  subnetworks.  Any  such  interfacing  subnetworks  found 
are  added  to  the  top  of  the  stack.  When  all  events  in  a subnet- 
work have  been  investigated  it  is  added  to  the  master  network 
and  removed  from  the  unexamined  stack.  When  the  unexamined  stack 
of  interfacing  networks  is  empty,  the  assembly  process  is  complete. 
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2.4.27.6  Functional  Block  Dxagram 


Place  master  subnetwork 
in  stack  to  be  analyzed 
for  interfaces. 


Empty  list  of  subnetworks 
previously  examined  for 
interfaces. 


Remove  current 
top  subnetwork  from 
the  unexarained 
stack  and  save  it. 


Select  top  element  from 
stack  of  subnetworks  to 
be  examined  for  interfaces 
and  decrement  stack  count. 


stack  of^ 
unexamined 
subnetwork 


Do  any\s^^ 
unexamined 
events  remain  in 
, saved  top  ^ 
^\subnetworkx^ 


Augment  master  sub- 
network with  current 
subnetwork.  Add  cur- 
rent subnetwork  to 
list  of  previously 
examined  subnetworks. 


ORIGINAL  PAGE  IS 
OF  POOR  QUALITY 


Does  next 

event  in  saved  top 
subnetwork  belong 
to  an  unexamined 
V subnetwork  ^ 


Add  those  unexamined 
interfacing  subnetworks 
of  the  current  event  to 
the  stack  of  subnetworks 
to  be  examined. 
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2.4.27.7  Typical  Applications 

This  module  may  be  applied  whenever  it  is  necessary  to  as- 
semble several  subnetworks  into  a master  network.  This  situation 
arises  frequently  in  heuristic  scheduling  where  several  subnet- 
works must  be  scheduled  simultaneously  because  their  activities 
share  common  resources.  Also  small  sjonetworks  may  be  assembled 
for  display  or  subsequent  critical  path  analysis.  However,  large 
subnetworks  because  of  computer  resource  limitations  will  require 
condensation  before  merging  using  the  two  m.odules  NETWORK_CONDENSER 
and  CONDENSEDJETWORKJIERGER,  respectively. 
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2.4.27.8  Detailed  Design 


The  functional  block  diagram  for  this  module  may  be  used  as  a flow  chart. 
The  first  subnetwork  to  be  examined  is  the  one  identified  as  the  master 
subnetwork,  i.e.  the  subnetwork  with  controlling  interfacing  events.  The 
name  of  the  subnetwork  to  be  analyzed  is  placed  in  the  examined  stack  and 
is  saved  for  future  reference.  Each  job  of  the  subnetwork  being  analyzed  is 
examined,  and  if  the  job.  is  an  event,  it  is  checked  foi;  interfaces.  The 
stack  remaining  to  be  examined  is  augmented  by  the  interfaces  of  this  event. 
Each  job  of  the  current  network  is  examined.  Events  not  Included  in  the 
assembled  network  are  added  to  network  C.  If  the  event  is  included,  then  the 
predecessor  set  of  the  event  in  the  assembled  network  is  augmented  by  the 
predecessor  set  in  the  current  network  and  the  result  placed  in  network  C. 

If  the  job  is  an  activity  and  is  included  in  the  assembled  network,  the  great 
duration  of  the  activity  is  included  as  the  activity  is  placed  in  network 
C.  If  the  activity  is  not  in  the  assembled  network,  it  is  added  to  C.  When 
all  jobs  of  the  current  subnetwork  have  been  examined,  the  assembled  network 
is  replaced  by  C and  the  process  repeated  for  the  next  subnetwork. 

2.4.27.9  Internal  Variable  and  Tree  Name  Definitions 

- list  of  jobs  which  have  been  examined. 

- list  of  job  names  in  the  assembled  network. 

- list  of  job  names  in  the  subnetwork  being  examined. 

- temporary  storage  for  a predecessor  name,  for  ease 
in  referencing. 

“ name  of  the  subnetwork  being  examined. 

temporary  structure  for  the  network  being  assembled. 

- temporary  storage  for  a successor  name,  for  case 
in  referencing. 
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$EXAMINED_STACK 

$NAME_A 

$NAME_B 

$PRED 

$SAVE_NAME 

$SUBNET_C 

$SUCC 


2.4.27o9  Internal  Variable  and  Tree  Name  Definitions 


$AS  SEMBLED_NETWORK 


$DUMMY 

$EVENT 

$EXAMINED_STACK 
$ INTERSECT 

$NAME_A 

$NAME_B 


The  completed  output  network  prior  to 
grafting  it  at  the  master  subnetwork 
node  of  $JOBSET 

Temporary  storage  for  the  name  of  the 
subnetwork  being  examined 

Identifier  for  each  subnode  of  $INTERFACE 

List  of  jobs  which  have  been  examined 

Output  set  returned  from  procedure  SET__ 
INTERSECTION 

List  of  job  names  in  the  assembled  network 

List  of  job  names  in  the  subnetwork  being 
examined 


$PRED 

$SAVE_NAME 

$SUBNET__C 

$SUCC 

$TEMP 

$TEMP_NAJdE 

$TEMP_NETS 

$TEMP2 


- Temporary  storage  for  the  predecessor 
liame,  for  ease  in  referencing 

- Name  of  the  subnetxrork  being  examined 

- Temporary  structure  for  the  network  being 
assembled 

- Temporary  storage  for  a successor  name, 
for  ease  in  referencing 

- Temporary  storage  for  $EVENT 

- Temporary  storage  for  the  current  activity 
or  event  being  examined 

- Identifier  for  each  subnode  of  $TEMP 

- Temporary  storage  for  the  name  of  the 
subnetwork  being  examined 


$UNEXAMINED_STACK  - List  of  jobs  yet  to  be  examined 

$UNION  - Output  set  returned  from  procedure  SET__UNION 

2.4.27.10  Modification  to  Functional  Specifications  and/or  Standard 
Data  Structure  Assumed 


None 
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2.4.27.11  Commented  Code 


nktwork^assembleri  procedure (*jobset»sinterf ace #smaster.subnet.id* 
ssubnetIset) 

OPTiONS(EXTERNaL)  I 

declare  SUNEXAMINEO-STACK»SEXaMINEd1STACK,STEMP..NAME*$SAVE_NAME  LOCAL! 
declare  STEMP*  STEMP^NETSf  STfMPZ  LOCaLI 

DECLARE  SNAME«A*  SNAME^B*  SDUmMY*  SEVENTi  SASSEWBLED^NETWORKt 
SSUBNET.Ct  SINTERSECT*  $SUCC*  SPREDt  I LOCALI 

IF  interface  identical  to  SNULL 

THEN  IF  SMASTER_SUBNET^ID  IDENTICAL  TO  SNULL 

Then  doi 

DO  I ■ number (SJOBSET)  TO  2 BY  -II 

DO  vJ  • NUMBER(SJObSET(I)  > TO  1 BY  -II 

GRAFT  SJOBSET(I)  (J)  AT  SJOBSET  (FIRSTMNEXTM 

END! 

PRUNE  SJOBSET (1)1 

END  I 

RETURNI 

ENDI 

else  DOI 

DO  I « number(Sjobset)  to  1 by  -II 

IF  LABELTSJOBSET(I) ) SMASTER-SUBNET.ID 
THEN  DOI 

DO  J ■ NUMBER(*J0BSET(I) ) TO  1 BY  -II 

GRAFT  SjOBSET(n(J)  AT  SJOBSET,#  (SMASTER.SUBNET.ID) 

(NEXT) I 

END  I 

PRUNE  SJOBSET (i) I 
enBi 
ELSE  I 
ENDI 
RETURNI 
ENDI 

ELSE  I 

/*  PLACE  Master  subnetwork  in  sta^k  to  be  analyzed  for  interfaces 
SUNEXaMINED  stack (FIRST)  ■ SMaSTEr£SUBnET_IO I 

/*  EMPTY  LIST  OF  SUBNETWORKS  PREVIOUSLY  EXAMINED  FOR  INTERFACES  ** 

prune  sexamined.stacki 

PRUNE  SASSEMBLEDlwETWORK(FlRSt) I 

P0INT.A*  ^ . 

/♦  SELECT  TOP  ELEMENT  FROM  STACK  OF  SUBNETWORKS  TO  BE  EXAMINED 
SEXaMINED.STaCK(NEXT)  ■ SUNEXAMINEDStSTACK(FIRST)  I 
/*  S/^VE  current  top  SUBNETWORK  FROM  THE  UNEXAMlNED  STACK  »y 

SSAVE«NAME  * $UNEXAMINED«STACK (FIRST)  I 
PRUNE  SUNEXAMINED.STACK(FIrST) I 
POINT^Bl  ^ 

DO  I « 1 TO  NUMbER(SJOBSET,#($SAVE_NAME) ) I 

IF  SJOBSET. W(SSaVEInAME)  (If. DURATION  IDENTICAL  TO  SNULL  ,, 

THEN  IF  SJOBSET,# ($SaVE|naME) (I) .JOB.INTERVAL  IDENTICAL  TO  SnULI 
THEN  DOI 

WRITE  fNElTHER.DURATION«NOR-JOB_INTERVAL^INPUT»» 

SSAVE.NAME  I 
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RETURN! 

END!  , . . 

ELSE  $JOBSET,#(SSAVE^tNAMEj.(  I)  .duration  ■ SJOBSET.# 
<SSaVE  NAMEMI)  .jOgliNTERVAL.END  - SJOBSET.# 
(SSAVE.NAME)  (D.JOBIiTNTERVAL.STARTI 


IF 


s 0 


ELSE! 

SJOBSET.# (SSaVE^NAME) <I) .DURATION 

Then  ooi 

DO  FOR  all  subnodes  OF  SINTERFACE  USING  SEVENTI 
PRUNE  STfMPI 

IF  SSAVifNAME  ELEMENT  OF  SEVENT 
then  STEMP  * SEVEnT! 

ELSE! 

label (SDUMMY)  = SSAVE^NAME! 

PRUNE  $TEMP(FIRSTI (SELEMENT  s LABEL ( SDUMMY) ) H 
IF  STEMP  (FIRST)  IDENTICAL  TO  SNljLL 
THEN! 

ELSE  DO! 

DO  FOR  ALL  SUBNoDES  OF  STEMP  USING  STEMP^NETS! 

IF  STEMP'^NETS  -•  ELEMENT  oF  SEXAMInED-STACK 

then  if  STEMPf^NETS  ELEMENT  OF  SUNEXAMlNEO.ST ACK 

unexamined  interfacing  subnetworks  of  the  current 

THE  STACK  OF  SUBNETWORKS  TO  BE  EXAMINED 

THEN  insert  STEmP_NFTS  BEFORE  SUNEXAMINED.ST ACK 
(NEXTi ! 

ELSE! 

ELSE! 

END! 

END! 

END! 

END! 

ELSE! 

END!  . 

AUGMENT  MASTER 
/*  OF  PREVIOUSLY 
START^AUGMENTATIONj 

IF  sASSEMBLED^NETWORK  identical  to  SNuLL 
THEN  DO! 

DO  I s number (SASSEMBLEo.NETWORK)  to  1 by  -u 

insert  SASSEM0LED_NETWORK(I)  before  SSUBNET.C(FIRST) I 


/• 

/* 


ADD  THOSE 
EVENT  TO 


SUBNETWORK  WITH  CURRENT  SUBNETWORK. 
examined  SUBNETWORKS 


ADD  TO  LIST 


END! 

END! 

DO  I = 1 TO  number (SASSEMBiED.NEJWORK) ! 

SNAME.A(I)  = LABEL(SASSEMBLED«NETW0RK(I) ) I 

end  ! 

DO  I - 1 TO  number (SJOBSET.# (SSAVE.NAME) ) ! 

SNAME_B(I)  = LABEL(SJOBsET.#($SAVE.NAME) (I) ) I 
END! 

DO  I 3 number (SNAME_B)  to  1 BY  -l! 

IF  SJOBSET. #(SSAVE_NAME) (I) .DURATION  = 0 

THEN  DO! 


♦ / 


♦ / 
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STEMP.NAME  (FIRST)  asSNAME.Bn:)  ? 

CALL  SETINTERSECTION(STEMP„.NAME?*fSlAME_A^SlNTERSECT)  I 
IF  SINTERSECT  identical  to  5NULL 

THEN  Graft  sjobset,(^ (Ssave^name)  d)  at  $subnet„C(nexT)  i 
ELSE  Dot 

CALL  SETUNIpN(SjOBSET»#($SAVE  NAME)(D* 

TEMPORALJreLATIONs  PREDECESSOR  ».SASSEMBLED«NETW0RK.' 
#(SNAME„R(I) ) ,TEMPORAL_RELATION,PREDECESSORf 
SUNION)! 

GRAFT  SUNIOn  AT  SSUBNET^C.# (SNAME^ ( I ) ) . 

TEMPORAL^^  relation*  PREDECESSOR  I 
END? 

END? 

ELSE  DOI 

SPREO  » SJOBSET.#(SSAVF1namE) (I) .TEMPORAL^RELATION. 
PREdECESSORI 

DO  J * 1 TO  NUMBEr(JJORSET.#($SaVE  NAME) ) I 
IF  SNAME^Sd)  element  OF 

SJObSET*#($SAVe_NAMF)  (jj  »TEMPORAL«RELATiON,PREDECE5;<?OR 
THEN  SSUCC  « LABEL(SJ0BSET,#(SSAVE.NAME) (J) ) I 

END? 

IF  (SPREO  SUBSET  oF  SASSEMBLED_NETW0RK.# (SNAMEIb ( I ) j , 
TFMPORAL.RELATtON. predecessor  &.  ^NAME^Bd)  ELEMENT  oF 
SASSEM8LED.NETwORK,« (SSUCC) .TEMPORAL^RELATION. 
PREDECESSOR) 

then  if  SJ08SEt.#($SAVeLnAmE) { I) , DURATION  > 
SASSEMBLED„NETW0RK*#($NAME«Bd)  ) .DURATION 
then  graft  SJOBSET.# ($SAVE„NAME) (I ) AT  SSUBNET  C 
(NEXT) I 

else  graft  SASSEMBLED»,NETW0RK.#($NAME_B(I)  ) AT 
SSUBNET^C(NEXT) f 

ELSE  graft  *JORSETe^($SAVE_NAME) d)  AT  SSUBnET^C (NEXT) | 
END? 

END! 

PRUNE  SASSEMBLED-.NETWORK? 

GRAFT  SSUBNET_C  AT  SASSEMBl'ED^NETWORK ? 

IF  SUNEXAMINED.STACK  -<  IDENTICAL  TO  SNULL 
then  go  to  POINT^A? 

ELSE  DOI 

graft  SASSEMBLEO^ETwORK  at  $JOBSET*#(SMASTER«SURNET«Id)  I 
graft  SEXAMInED^STACx  at  ssubnet^set? 
do  I = NUMBER (SJOBSfT)  TO  2 bY  «1| 

STEMP2  * LABEL(SJ08SET(I) ) ? 

IF  STEMP2  element  OF  SSUBn£t|SET 
THEN  PRUNE  SjOBSEfd)? 

IF  $U0BSET(I> (FIRST)  IDENTICAL  TO  SNULL 
THEN  PRUNE  SjOBSEfd)? 

ENDI 

DO  l«  NUMbER(SJ08sET.#($MASTE^^SUBNET_ZD) ) TO  1 BY  ~lf 
IF  $JOBSET,«($MASTer1suBNET„IO) (I) .TEMPORAL-RELATION, 
PREDECESSOR(FlRsf ) IDENTICAL  TO  SNULL 
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THEN  PRUNE  SJOBSeT,# (SMASTER_SUBNET«ID) ( I ) . 

temporal.relationi 

ENOI 

CALL  REDUnDANT.PREDEcESSoR^CHECKER (SJOBSET .# 
(SMASTER.SUrNET.IO) ) I 

RETURN I 
END! 

END  NETWORK.ASSEMBLERI 
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2.428  CRITICALJATH 
PROCESSOR 


2.4.28  CRITICAL_PATH_PROCESSOR 

2.4.28.1  Purpose  and  Scope 

Given  e master  subnetwork  snd  its  prescribed  iiiterfacxng 
events,  this  module  will 

1)  Integrate  the  master  subnetwork  and  all  of  its  interfacing 
subnetworks  into  a condensed  master  network. 

2)  Compute  the  early-  and  late-occurrence  dates  of  all  the  in- 
terface events. 

3)  Compute  all  critical— path  data  for  the  activities  in  the 
master  subnetwork  and  all  of  its  interfacing  subnetworks. 

The  objective  of  the  module  is  to  facilitate  critical  path 

calculations  on  networks  too  large  to  permit  direct  computations 
because  of  computer-  resource  limitations  in  high-speed  memory 
and  execution  time. 

2.4.28.2  Modules  Called 
NETWORK_CONDENSER 
CONDENSED_NETWORK_MERGER 
CRITICAL_PATH_CALCULATOR 
PREDECESSOR  SET  INVERTER 
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2.4.28.3  Module  Input 

1)  Intei'face  Event  Definitions  ($INTERFACE) 

$INTERFACE 

(EVENT 
IDENTIFIER) 

OF 

SUBNET) 

This  data  structure  is  illustrated  in  2.4.28-i  for  the 

subnetwork  complex  of  Fig.  2.4.28-2 

2)  Subnetwork  Definitions,  Including  Master  Subnetwork  ($J0BSET) 


$J0BSET 


3)  Master  subnetwork  identifier  ($MASTER_SUBNET_ID) 

$MASTER_SUBNET_ID 

(SUBNET  ID) 

2.4.28-2 
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1 


t 


2.4.28.4  Module  Output 

1)  Identifiers  of  subnetworks  that  are  components  of  total  net- 
work (all  subnetworks  in  $J0BSET  may  not  be  connected  to  total 

network) . 


$SUBNET  SET 
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2.4.28.5  Functional  Description 


This  module  has  three  basic  objectives.  The  first  objective, 
assembling  the  subnetworks  into  a 'condensed'  self-contained  master 
network,  is  the  most  involved  and  facilitates  ready  accomplishment 
of  the  remaining  two.  Basically,  it  involves  determining  all  of 
the  subnetworks  to  which  the  specified  master  subnetwork  is  con- 
nected by  interface  events.  These  subnetworks  are  condensed  and 
then  merged  into  a condensed  master  network.  These  steps  can 
best  be  accomplished  in  the  recursive  fashion.  (See  para  2.4,28.6.) 

The  master  condensed  network  is  initialized  as  the  condensed 
master  subnetwork.  Next  a 'pushdown'  stack  of  interfacing  sub- 
networks is  created  and  initialized  as  the  master  subnetwork. 

Then,  the  top  subnetwork  of  the  stack  is  condensed  and  examined 
for  interfacing  subnetworks.  All  unanalyzed  subnetworks  found 
are  added  to  the  stack.  When  the  interface  examination  of  a 
given  subnetwork  is  completed,  it  is  merged  into  the  current  con- 
densed master  network.  The  merging  process  will  be  carried  otjt 
by  the  module  CONDENSED_NETWORK_HERGER , When  the  'pushdown' 
stack  of  unexamined  interfacing  subnetworks  is  finally  emptied, 
a self-contained  master  condensed  network  has  been  assembled  and 
is  ready  for  critical-path  analysis. 

The  second  objective  of  the  module,  calculation  of  the  early 
and  late  occurrence  dates  of, all  the  interfacing  events,  is  ac- 
complished by  applying  the  module  CRITICAL_PATH_CALCULATOR  to  the 
condensed  master  network.  To  do  so  one  need  only  construct  the 
single  tree  SJOBSET,  including  the  successor  set  substructure. 
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required  by  the  module  CRITICAL ^PATH CALCULATOR.  This  input  treo 

contains  the  network  topology  and  duration  information  necessary 
for  critical  path  analysis  and  can  most  conveniently  be  accumulated 
as  the  condensed  master  network  is  built.  The  successor  sets 
can  be  built  from  the  predecessor  sets  by  the  module  PREDECESSOR_ 

SET  INVERTER  after  the  remainder  of  the  tree  is  accumulated. 

The  third  object  of  the  module,  computation  of  the  critical 
path  data  for  the  activities  in  the  various  subnetworks,  is  also 

achieved  by  a simple  call  to  the  CRITICAL PATH CALCULATOR.  This 

is  possible  provided  $J0ESET  contains  the  early-  and  late-occurrence 
date  of  each  interface  event.  The  input  data  structure  $J0BSET 
must,  of  course,  be  filled  with  the  network  topology  and  the  ac- 
tivity durations  for  the  particular  subnetwork  in  question.  In 
particular  the  successor  sets  as  well  as  the  predecessor  sets 
must  be  present  in  the  tree.  Hence  a call  to  the  PREDECE5iS0R_ 

SET  INVERTER  module  is  required. 
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2.4.28.6  Functional  Block  Diagram 


I Add  those .unexamined 
1 interfacing  subnetworks 
1 of  the  current  event  i 

i to  the  stack  of  subnetworks 
; to  be  analyzed  and 
increment  the  stack 
count  accordingly. 


Run  critical  path  j 
analysis  on  condensed'! 
master  network.  1 


1 

Initialize  stack  of  subnetworks  j 

to  undergo  critical-path  analysisj 
to  be  identical  to  stack  of  sub- 
networks that  underwent  interface 
(analysis . 

L 1 — 


Perform  critical-path  ! 

analysis  on  top  element  j 

of  stack  using  event  early  ; 
'•  and  late  occurrence  times  • 

* computed  from  condensed  master  1 
I network.  Decrement  stack  county 
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2.4.28.7  Typical  Application 


The  primary  application  of  the  module  is  to  permit  critical 
path  analyses  of  networks  too  large  for  the  computer  to  handle  as 
a single  piece;  it  also  permits  network  analysis  using  hierarchical 
levels  of  detail.  Critical  path  data  are  obtained  for  high-level 
milestone  events  reflecting,  without  approximation,  the  effects 
of  low-level  activities.  The  savings  in  high-speed  memory  re- 
quirements and  execution  time  can  be  considerable.  Furthermore, 
data  input  tends  to  be  more  accurate  when  the  networks  involved 
are  of  comprehensible  size.  In  general,  critical  path  analyses 
based  on  subnetworks  consistent  with  the  normal  hierarchical  de- 
composition of  the  project  is  the  most  effective  approach  to  the 
scheduling  and  control  of  large  projects. 

2.4.28.8  References ; 

Burraan,  P.  J.:  NetworP.s  for  Project  Planning  and 

Control^  McGraw  Hill,  London,  1972. 

IBM:  Project  Management  System  IV,  Uetwork  Processor  Progrojri 

Desc't^vption  ana  Operations  Manual,  Publication  SH20-0899-1,  1972. 
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2.4.28.9  Detailed  Design 


The  functional  block  dlagraa  may  be  used  as  the  flowchart  for  this 
module.  The  module  first  selects  the  master  subnetwork  and  condenses  it 
by  a call  to  module  NETWORK_COKDENSER.  The  name  of  the  subnetwork  is 
added  to  the  stack  of  examined  subnetworks.  Each  element  of  the  current 


subnetwork  is  examined,  and  if  events  (i.e.  duration  equals  zero)  have 
Interfaces  with  subnetworks  not  in  the  examined  stack,  the  interfaces  are 
added  to  the  unexamined  stack.  When  all  elements  have  been  examined,  the 
condensed  master  network  is  augmented  with  the  current  subnetwork.  This 
process  la  repeated  until  all  subnetworks  have  been  examined.  A critical 
path  analysis  is  run  on  the  condensed  master  network,  by  a call  to  module 
CRITICAL_PATH__CALCULATOR.  Each  subnetwork  which  was  examined  for  inter- 
faces is  subjected  to  critical  path  analysis  using  event  early  and  late 
occurrence  times  computed  from  the  condensed  master  network. 

2.4.28.10  Internal  Variable  and  Tree  Name  Definitions 


$CONDENSED  MASTER 


$CONDENSED  SUB 


$EXAMINED  STACK 


a tree  structure  representing  a master  net- 
work containing  interface  events  and  critical 
delays . 

a tree  structure  containing  one  of  the  input 
subnetworks  in  condensed  form. 

a temporary  tree  v;hose  first  level  subnode  values 
are  the  labels  of  the  subnetworks  which  have 
been  examined  for  Interfaces. 
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$DUMMY  - Temporary  storage  at  first  subnode  for  sub- 

networks, used  for  call  to  procedure  PREDE- 
CESSOR_SET_INVERTER 

NIJMBER_DELAY  - Counter  used  in  calls  to  procedure,  NETWORK_ 

CONDENSER,  so  that  the  identified  delays  be- 
tween events  are  numbered  consecutively 

$ORDERED_MASTER  - The  condensed  master  subnetwork  following, 

critical  path  analysis 

$ORDERED_STACK  - 'Any  of  the  subnetworks  following  critical 

path  analysis 

$TEMP  - A temporary  tree  whose  single  subnode  is  the 

label  of  the  condensed  master  subnetwork 

$TEMP_NAME  - A temporary  tree  whose  single  subnode  is  the 

label  of  the  subnetwork  element  being  exam- 
ined 

$UNEXAMINED__STACK  - A temporary  tree  whose  first  level  subnodes 

are  the  labels  of  the  subnetworks  yet  to  be 
examined  for  interfaces 

2„4.28oll 

Data  Structures  Assumed 

Since  only  one  set  of  job  elements  forming  a subnetwork  are  exam- 
ined with  each  call  to  this  module,  the  subnetwork  is  transmitted 
through  the  parameter  list  as  $SUBNET_SET«  The  first  level  subnodes 
of  $JOBSET  will  be  only  subnetwork  identifiers,  MASTER__SUBNET_^ID 

will  not  be  a sunbnode  of  $JOBSET,  Instead,  a single  node  tree, 
$MASTER__SUBNET_ID,  will  be  used  to  identify  the  master  subnetwork. 
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2.4.28.12  Conuaanted  Code 


CHITICAL-PATH«PR0GESS0R  t PROCEDURE  < SJOBSET ♦ SINTERFACE* 
SMASTrRlsuBNET«lD#$SUBNET„SET)  OPTIONS  (EXTERNAL) I 

declare  numbeo.delay  locals 

DECLARE  I*J*SOROERED.MASTER*$ftRDERED„STACKt$TEMP  LOCALI 

DECLARE  SUNEXAMINEd.STACK*$EXaMINED_STACK JSCONDENSED_MASTEP*STEMPiNAMF» 

$oummy#$condenseo^sub  LoC.ALI 

/*  PLACE  LABEL  OF  MASTER  SUBNETWORK  IN  STACK  TO  BE  EXAMINED  */ 

sunexaMined^stackcfirst)  = smasterIsubnET.idi 

PRUNE  SEXAMINED^STaCKI 

PRUNE  SCONDENSEdIMASTER (FIRST) ; 

NUMBER.OELAY  * II 

/*  MAKE  TOP  element  OF  STACK  TO  BE  EXAMINED  ‘CURRENT*  */ 

/*  CONDENSE  current  SUBNETWORK 

PGINT^A: 

CALL  NETWORK_COnDENSER(NUMpER_DELAY»SUOBSET,#($UNEXAMINED_STaCK 
(FIRST) ) *SCONDENSEO«SUB) I 
GRAFT  SCONDENSED..SUB  AT  SDuMMY  (FIRST)  I 
CALL  PREOECESSOR.SET_INVERtER (SDUMMY) I 
graft  $DUMMY(FIRST)  at  sconoensedIs^bi 
LABEL (SCONDENSED.SUB)  * SUmEXAMINEOsJSTACK (FIRST) ? 

/•  ADD  CURRENT  SUBNETWORK  TO  STACK  OF^EXAMINED  •/ 

$EXAMINED„STaCK(NEXT)  * SUMEXAMINEOrSTACK(FIRST) I 
PRUNE  SUNEXAMINeD.STACK (FIRST) I 
POINTS* 

/♦  DO  ANY  UNEXamInED  ELEMENTS  REMAI^4  jN  CURRENT  SUBNETWORK?  */ 

DO  I = 1 TO  NUMBER(SCONDENSED^SUB) I 
IF  SCONDENSEoISUB(I) .JOB_InTERVAl  identical  TO  SNULL 
Then  if  SCONOENSEO_SUB(i) .duration  IDENTICAL  TO  SNULL 
THEN  DOI 

WRITE  ♦NEITHER^OUPATION.NOR-JOB.INTERVAL^INPUT* ♦ 

label  (scondfnsed!:sub(1)  > i 

RETURNI 
END  I 
ELSE! 

ELSE  DOI 

SC0NDENSED-SUB( I ) .START. early  a SCONDENSED^SUR ( I ) . 

JOB  INTERVAi'. START! 

SC0NDENSED_SUB(I) .START.LATE  « SCONDENSED^SUB ( I ) . 

JOB  interval, start? 

SCONOENSED^SUB(I) .FlNlSHtEARLY  s SCONDENSEO.SUB ( I ) . 
jOBljNTERVAi'.ENDI 

scondensed_sub(I) .FINISH. late  s SCONOENSED^SUR ( I ) . 

JOB' interval. ENDI 

IF  SCONDENSED'SUB(I) .duration  identical  to  SNULL 

THEN  SCONDENSED„SuB (I ) .duration  = SCONDENSEO^^SUB ( I ) , 

JOB^INTERVAl.ENO  - SCONDENSED.SUBd)  .JOB.InTErVaI'. 
start? 

END  I 

/*  IS  THIS  element  an  EVENT?  */ 

IF  SCONOENSEDl.SUB(n  cDURATtON  * 0 
then  DOI 
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interfaces  with  subnetworks  not  in 


*/ 


/* 


/*  DOES  THIS  EVENT  HAVE 

/*  examined  stack? 

STEMP_NAME  = LABEL ( $C0NDENSED_SUB ( I ) ) I 
DO  j = 1 TO  number (^interface?# ($TEMP_NAME) ) I 
IF  SINTERFACE.^ ($TEMp_NAMF) ( jj  -»ELEMENT  OF  $EXAMINED«ST ACK 
then  If  $INTERFACFt^«$TEMP„NAME) { J)  -•  ELEMENT  OF 
SUNEXAMINED_STaCK 

/*  ADO  THE  UNEXAMINED  INTERFACES  TO  THE  ilNEXAMlNED  STACK  , ^ ■»/ 

then  SUNEXAMINEDIstACK (NEXT)  = SINTERFACE.# ($TEMP_NAME) 

(J5  S 

ELSE  I 

else? 

END? 

END! 

ELSE! 

^AUGMENT  THE  CONDENSED  .MASTER  NETWORK  WIJH  CONDENSED  CURRENT  */ 

CALi-  C0NDENSED_NETW0RK„MERfiER  (Sr:ONDENSEDlMASTER»$CONDENSED„SUB)  ? 
label  (SCONOENSED„mASTER)  = $MaSTER_SU8NET_IDI 
PRUNE  SCONDENSFDISUR; 

/*  IS  STACK  OF  UNFXAMTNED  SUpNETWORKS  EMPTY? 

IF  SUNEXAMINE0_STACK  IDEmTICaI  to  snull 
then  go  to  PoINtIa? 

Else  doi 

/*  RUN  critical  Path  analysis  on^ condensed  master  network 

STEMP  = label (SCONDEmSEDImASTERM 
graft  SC0NDENSED„MASJER  at  SDUMMY(EIRST) I 
CALL  PREDECESSOR3ET'  INVERTER  ( SDUMMY)  ? 
graft  SDUmMY  (FIRST)  AT  SCONDENSED-.MASTER ? 

LABEl  (SCONDENSED^MAStEP)  « STEMP? 

CALL  CRTTlCAL_PATH,CALCULATOR(SCONOENSED_MASTERt 
SORDERED^MASTER) ; 

graft  SORDEREO.MAsTEp  AT  fCONJDENSED„MASTERI 
DO  I = 1 TO  NUMBER($fXAMINED_STACK) ? 

DO  J = 1 TO  number (SJORSETe^ <$EXAMINED„STACK ( I ) ) ) I 
IF  sjobset,#(®examinedLstacK(I) ) (J) .duration  s 0 
THEN  DO?  ■ 

SJ0PSET.#($FXAMIMED_STACK(I) ) (J) .START  a „ 

SCONDENSpnlMASTFRo^l-ABEL ( SJO0SET.# ($EXAMlNED|sTArK 
(I) ) { J) ) .sjaRti 

$J0RSET.#(SfXAMIwED1sTACK{1) ) (J) .FINISH  a _ ^ 

$CONOENSFOlMASTER.??LABEL(SjOBSET.#{$EXAMlNEDfsTArK 
(I ) ) (J) ) .FJNISHI 

95JORSETo#(SfXAMINED_STACK(I)  ) (U)  .SLACK  = , - 

SCONDENSFOlMASTERa^LABEL (SJOBSET.# ($EX AMI NE0|S TACK 
Cl) ) (J) ) .SLACK? 

END? 

END? 

/*  PERFORM  critical  PATH  ANALYSIS  ON  TOP  ELEMENT  OF  STACK  THAT  HAS 
/*  BEEN  examined  FOR  INTERFACES.  USE  EVENT  EARLY  AND  LATE  f/ 

/*  occurrence  TIMES  computed  from  condensed  master  network  */ 
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GRAFT  SJOBSET.#(SEXAmINE0LsTACK<I) ) AT  SDUMMY (FIRST) « 

CALL  PREOECESSOR-SETf^lNVERTER  (SDUMMY)  I 

graft  SDUMMY(FIRST)  AT  $J0BSET.<^($EXAMINED«STACK(J) ) I , 
CALL  CRITlCAL_PATH„CALCULATOR(SJOBSET,#(SEXAMiNED_STACK(I) > * 
SORDERED.STaCK) « , ^ 

graft  SORDERED.STACK  at  $J0BSET.#($EXAMINED.STACK(I) ) I 


ENDI 

ENDI 

GRAFT  SEXAMINED_STaCK  AT  SSUBnET.SFTI 
END!  /*  CRITICAL.PATH^pROCESSOR 
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2.4.29  NETWORK  EDITOR 


2. A. 29  NETWORK_EDITOR 

2.4.29.1  Purpose  and  Scope 

This  module  edits  manually  or  automatically  generated  project 
scheduling  precedence  relations  for  logical  inconsistencies. 

Four  types  of  errors  may  occur  in  precedence  data: 

1)  The  predecessor  relationships  may  contain  cycles;  for  example, 
'job  A is  a predecessor  of  job  B,  B is  a predecessor  of  C, 

and  C is  a predecessor  of  A. 

2)  The  list  of  predecessors  for  a job  may  include  more  than 
immediate  predecessors;  for  example  job  A is  a predecessor 
of  B,  B is  a predecessor  of  C,  and  A as  well  as  B are  listed 

as  predecessors  of  C. 

3)  ^ Some  precedence  relations  may  be  overlooked. 

4)  Some  predence  relations  may  be  listed  that  are  spurious. 

Errors  of  types  (1)  and  (2)  are  inconsistencies  in  the  data  that 
can  be  detected  by  automated  examination  of  the  predecessor  sets. 

, Errors  of -types  (3)  and  (4),  however,  appear  to  be  legitimate 
data  and.  hence,  cannot  be  discovered  by  computer  procedures. 
Instead,  manual  checking  (perhaps  by  a committee)  is  necessary 
to  ensure  that  the  predecessor  relations  are  correctly  reported. 

Errors  of  type  (1)  are  fatal  to  the  critical  path  analysis. 
Errors  of  type  (2),  however,  are  not  fatal  and  merely  lengthen 
the-execution  of  the  critical  path  algorithm.  For  this  reason 
the  NETW0RK_EDIT0R  has  been  divided  into  two  separate  editing 
procedures.  The  first,  called  ORDERJYJREDECESSORS , is  manda- 
tory. All  efficient  CPM  processors  require  the  job  set  to  be 
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arranged  in  a technological  ordering  (any  job  in  the  list  precedes 
all  o£  its  successors) . This  ordering  is  a useful  byproduct  of 
the  cycle-checking  routine.  The  second  procedure,  called  the 
REDUNDANT_PREDECESS0R_CHECKER,  is  optional.  Its  use  is,  how- 
ever, recommended  because,  in  addition  to  expediting  the  critical 
path  processing,  it  generates  the  most  logically  concise  prece- 

dence  network  possible. 

2.4.29.2  Modules  Called 
0RDER__BY_PREDECES50RS 
redundant_predecessor_checker 

2.4.29.3  Module  Input 

1)  Network  definition  $J0BSET  - unedited  version 

2)  Redundant-predecessor-elimination  option  indicator  (SIMPLIFY) 


$J0BSET 
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2.4.29.4  Module  Output 

1)  Network  definition  $J0BSET  - edited  version 

2)  Cycle-containing  subset  of  activities  or  events  $CYCLE_SET 


$CYCLE_SET 


2.4.29.5  Functional  Description 

The  module  NETW0RK_EDIT0R  serves  primarily  as  a coordinator 
of  the  two  editing  modules,  ORDER_BY_PREDECESSORS  and  REDUNDANT — 
PREDECESSOR_CHECKER.  This  module  is  intended  to  prevent  the 
user  from  attempting  to  use  REDUNDANT_PREDECESSOR_CHECKER 
without  first  having  called  ORDER_BY_PREDECESSORS  to  place  the 
second  level  subnodes  of  $J0BSET  in  a technological  ordering. 
The  user  may  opt  not  to  eliminate  redundant  predecessors  by 
setting  the  flag  SIMPLIFY . 


2.4.29-3 
Rev  B 


2.4.29.7  Typical  Application 


Removal  of  logical  inconsistencies  from  a precedence  network 
is  necessary  in  two  contexts. 

1)  Facilitating  an  automated  critical  path  analysis. 

2)  Preparing  a consistent  and  concise  precedence  network  for 
manual  analysis  to 

a)  Eliminate  errors  of  types  (3)  and  (4)  as  discussed  in 
. 2.4.29.1. 

b)  Improve  the  basic  project  organization. 

2.4.29.8  Reference 

Levy,  F.  K.,  Thompson,  G.  L.,  and  Wiest,  J.  D.:  "The  ABC's  of 

the  Critical  Path  Method."  HuwcLi'd  Busvriess  Rev’^aWi  Vol  41, 

No.  5,  September -October  1963,  pp  98-107. 
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2.4.29.9  DETAILED  DESIGN 


This  module  simply  consists  of  a call  to  ORDER_BY__PREDECESSORS  and 
an  optional  call  to  REDUNDANT_PREDECESSOR_GHECKER.  Since  the  functional 
definition  of  the  parameters  used,  to  call  ORDER_BY_PREDECESSORS  have  been 
changed,  those  changes' have  also  been  incorporated  into  this  module.  After 
■•'.ailing  this  module,  the  user  should  always  check  $JOBLIST. FIRST  to  see  if 
it  is  identical  to  $NULL.  If  not,  the  user  can  assume  $JOBLIST  contains 
a set  of  jobs  containing  a cycle  and  REDUNDANT_PREDECESSOR__CHECKER  was 
not  called  (regardless  of  the  option  specified  in  the  CALL  statement). 

If  $JOBLIST  is  empty,  the  user  can  assume  $ORDERED_LIST  contains  the 
complete  set  of  jobs  and  REDUNDANTJPREDECESSORjCHECKER  was  called  (assum- 
ing that  option  was  specified). 

2.4.29.10  INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 

I_ELIMINATE_REDUNDANCY_FLAG  - Used  to  indicate  whether  or  not  REDUNDANT^ 
PREDECESSOR_CHECKER  is  to  be  called 
$J0BLIST  - Is  the  set  of  jobs  to  be  edited 

$0RDER  LIST  - Is  the  edited  set  of  jobs  output  by  the  module 

2.4.29.11  MODIFICATIONS  TO  FUNCTIONAL  SPECS  AND /OR  STANDARD  DATA 
STRUCTURES  ASSUMED 

In  order  to  make  this  module  compatible  with  the  restart  capability 
provided  in  ORDER_BY  PREDECESSORS,  its  parameters  have  bepn  redefined. 
$J0BLIST  has  been  substituted  for  $J0BSET,  This  is  because  all  of  the 
job  nodes  need'  to  be  one  level  below  the  root  node,  i.e.,  the  SUBNET  ID 
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nodes  of  $JOBSET  should  not  be  present.  This  tree  is  still  used  to  input 
the  unedited  list  of  jobs.  However,  as  the  jobs  are  ordered,  they  are 
transferred  to  $ORDERED_^LIST.  If  a cycle  is  detected,  the  set  of  jobs 
containing  the  cycle  is  returned  in  $JOBLIST,  thus  eliminating  the  need 
for  $CYCLE_SET.  $ORDERED_LIST  is  the  output  tree  of  this  module,  but 
also  can  be  used  to  input  an  already-ordered  list  of  jobs.  For  better 
readability,  the  name  of  the  option  flag,  SIMPLIFY,  has  been  changed  to 
I_ELIMINATE  REDUNDANCY  FLAG. 


2.4.29.12  COMMENTED  CODE 


nItwork^editorj 

/♦ 

/*  THIS  MODULE  CHECKS  FOR  LOGICAL  INCONSISTENCIES  IN  A SET  OF  i»/ 

/*  predecessor  relations.  On  output.  $ordered_list  will  conTajn  */ 
/*  The  jobs  (Input  in  sjoblisT)  in  precedence  order,  sordered^  */ 
/*  list  may  also  be  used  to  input  a previously  ordered  list,  if 
/*  cycle  is  detected,  the  module  immediately  returns,  leavins  the  */ 

/*  set  of  jobs  CONTAININO  the  cycle  in  SJOBLIST.  THE  INPUT  VARI-.  */ 

/*  ABLE  » I_ELIMINaTE1.REDUn0AnCY.FLAG«  INDICATES  WHETHER  OR  NOT  »/ 

/»  redundant  predecessor  RELATIONSHIPS  ARE  TO  BE  ELIMINATED.  */ 

/*  »/ 

procedure  (SJOBLIST*  iIeL ImINaTE„REDUNDANCY_FLAG . SORDEREoIlIST) 
OPTIONS(EXTERNAL) 5 

CALL  ORDER^BvIPrEDECESSORS {SJOBLIST. SORDERED.LIST)  I 
IF  SJOBLIST(FIRST)  not  identical  to  snull  then  return  i 

IF  I_ELIMTNATF.REOUNDANcY_eLAG  0 

then  call  REDUNDANT_PREnECESSORlcHECKER(SORDERED.LlST)  » 

END  NETWORK..EDITOR  * 
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2.4.30  CHECK_DESCRIPTOR_COMPATIBILITY 
2,  .4.30.1  Purpose  and  Scope 

This  module  identifies  incompatibilities  between  resource 
descriptors  that  arise  when  a single  job  is  to  be  inserted  on  a 
timeline  that  contains  jobs  that  have  already  been  assigned.  It 
applies  to  jobs  that  change  the  descriptors  of  one  or  more  spe- 
cific resources  or  that  require -resources  with  particular  values 
of  explicit  resource  descriptors.  For  example,  a certain  activity 
might  require  a camera  with  unexposed  film.  The  same  activity 
could  leave  the  film  in  an  exposed  status;  i.e.,  change  the  value 
of  the  film  status  from  ’unexposed'  to  'exposed.'  If  an  attempt 
is  made  to  schedule  this  activity  ahead  of  another  activity, 
which  has  already  been  assigned  to  the  timeline  and  whxch  requxres 
unexposed  film,  a resource  descriptor  conflict  would  result. 

This  module  will  identify  such  conflicts  when  given  an  existing 
schedule  and  a job  to  be  inserted  in  that  schedule  at  a specified 

time . 

It  is  Important  to  understand  that  this  module  is  applicable 
to  models  with  resources  that  have  multiple  explicit  descriptors, 
but  it  is  not  suitable  for  use  with  resources  that  are  described 
as  pools.  Pooled  resources  with  multiple  descriptors  are  extremely 
complex  to  model  due  to  a proliferation  of  partitions  of  the 
pool.  A discussion  of  modeling  and  solution  strategies  for 
pooled,  explicit-descriptor  resources  is  found  in  Volume  II.  The 
area  of  applicability  of  this  module  is  illustrated  as  follows. 
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Time  Progressive 
Assignment  Algorithms 

Time  Transcendent 
Assignment  Algorithms 

Implicit 

Descriptors 

Only 

Explicit 

Descriptors 

Implicit 

Descriptors 

Only 

Explicit 
Descrip  tors 

Item  Specific 
Resources 

This  Module 
Applicable 

This  Module 
Applicable 

Pooled 

Resources 

Poor 

Assignment 
Strategy 
for  This 
Type  of 
Modeling 

This  module  looks  forward  and  backward  in  the  input  schedule 
from  the  assignment  time  for  the  job  to  be  inserted.  It  searches 
backward  to  identify  the  jobs  in  the  input  schedule  that  place 
resources  in  improper  statuses  for  use  by  the  job  to  be  inserted. 
The  jobs  in  the  schedule  that  create  improper  values  of  descriptors 
are  identified  and  may  or  may  not  be  those  that  immediately  pre- 
cede the  job  to  be  inserted. 

Similarly,  this  module  looks  forward  in  time  to  identify  the 
jobs  in  the  schedule  that  no  longer  xizill  have  resources  with 
correct  descriptor  values  if  the  job  to  be  inserted  is  placed  in 
the  schedules  at  the  input  assignment  time.  The  module  neither 
makes  assignments  nor  cancels  assignments,  but  merely  builds  a 
tree  structure,  which  contains  information  that  is  useful  for 
identifying  the  cause  of  conflicts. 

This  module  assumes  that  the  absence  of  a final  descriptor 
means  that  the  job  does  not  change  values  of  the  resource  that 
were  input  to  the  job.  If  the  required  resource  descriptors  for 
the  job  to  be  inserted  are  incompatible  with  the  existing  resource 
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descriptors  at  the  assignment  time,  the  incompatibilities  that 
are  identified  for  times  after  the  assignment  time  are  those 
that  result  assuming  compatibility  between  the  scheduled  resource 
descriptors  and  the  required  descriptors  for  the  job  to  be  in- 
serted. This  is  illustrated  below. 

Time 

1 2^ — — n ^7^  ^ 

Scheduled  Job  to  be  Scheduled 

Job  1 Inserted  Job  2 


Incompatibility  Incompatibility 

2.4.30.2  Modules  Called 

DESCRIPTOR_PROFILE 

2.4 1 30.3  Module  Input 

This  module  is  called  with  three  input  arguments.  They  are  $C0N_CHECK 
$RESOURCE,and  $SCHED_UNIT.  $RES0URCE  has  the  general  structure 
given  in  Section  2.2  and  must  contain  initial  descriptors  at  a 
reference  time  arid  all  assignment  and  descriptor  changes  that 
are  to  be  considered  after  that  time.  This  information  is  re- 
quired by  this  module  so  that  it  can  call  DESCRIPTOR_PROFILE . 

$C0N__CHECK  is  a string  variable  flag,  used  to  indicate  if  contin- 
gency variables  are  to  be  examined. 
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2.4.30.4  Module  Output 

This  module  returns  a structure  called  $DESCRIPT0R_C0NFLICTS , 
which  contains  information  about  the  conflicts  that  would  result 
if  $SCHED_UNIT  were  assigned  at  its  specified  time.  The  general 
structure  of  $DESCRIPTOR_CONFLICTS  is  shown  below: 


$DESCRIPTOR_CONFLICTS 


Each  first-level  subnode  represents  a resource  status  conflict 
that  would  result  from  the  assignment  of  $SCHEDJJNIT  at  the 

specif ied  time . 
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$SCHED_UNIT  has  the  general  structure  of  a schedule  unit 
shown  below: 


$SCHED_UNIT 


Note  that  in  $SCHED_UNIT,  the  JOB_INTERVAL .START  must 
contain  the  assignment  time  for  the  job  to  be  inserted 


% 
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2.4.30.5  Functional  Block  Diagram 


For  each  required  resource 
of  Che  job  CO  be  inserted, 
determine  resource  descriptor 
values  at  the  assignment  time 
for  the  Job  to  be  inserted. 

Call  descriptor_profile 

repeatedly  to  perform  this 
function  i 


Select  one  required 
resource  for  job  to 
be  inserted. 


Are 

✓^the  descriptor 
values  of  Chat  resource 
compatible  with  those 
produced  by  the 
schedule  ? 


Update  resource 
descriptors  to 
start  time  of 
subsequent  job. 


Select  an  output  resource 
from  job  to  be  inserted. 


Find  next  later  scheduled 
job  Chat  changes  the 
descriptors  of  chat 
resource  (Call  this  job,  J^) 


all  output 
resources  from  job 
to  be  inserted  been 
considered 


Find  last  previous 
job  chat  changed 
the  descriptors  of 
that  resource. 


Select  next  job  that  starts 
equal  to  or  after  assignment 
time  for  job  to  be  Inserted. 


Build  a conflict 


this  job  scheduled 


/ Have  ^ 
all  required 
resources 
been 

considered 


Build  a 
conflict 
node . 


Ace 

nhe  descriptors 
produced  by  job  to  be 
inserted  compatible 
with  those  required 
V.  by  this  job? 


fOOB 
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2.4.30.6  Typical  Application 

The  most  common  use  of  this  module  is  to  service  an  assignment 
procedure  that  makes  assignments  in  a time-transcendent  manner; 
i.e.,  in  a sequence  that  is  not  ordered  on  time,.  Such  an  assign- 
ment sequence  might  be;  Assign  job  1 at  9:00  AM,  assign  job  2 
at  9:30  AM,  assign  job  3 at  9:18  AM.  If  each  of  these  jobs  has 
required  resources  with  particular  descriptors,  then  the  insertion 
of  job  3 between  jobs  1 and  2 can  cause  an  otherwise  compatible 
schedule  to  become  incompatible.  Incompatibilities  such  as  these 
are  identified  by  this  module. 

An  example  of  the  function  of  this  module  is  instructive. 
Consider  a resource-feasible  schedule  consisting  of  4 jobs,  Jl, 

J2,  J3,  and  J4 , and  two  resources,  R1  and  R2 , each  of  which  may 
have  one  of  three  descriptor  values  denote  by  SI,  S2  or  S3. 

Suppose  the  assignments  for  Jl  through  J4  are  represented  by  the 
timeline  below. 

Jl  J2  J3  J4 

■ 1— Ibhh la* — 

31  34 
S3 

S2 


Input  Descriptors 
Requirements 


R1 

R2 


12 


17 


24  26 


S2  s. 


3 

Si 


Output  Descriptors 
R1  S2 

R2  Si 
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And  suppose  that  the  job  to  be  inserted  is  represented  as: 

J5 


Input  Descriptor 
Requirements 


R1 

R2  ^2 

Output  Descriptor 

R1 

R2 


This  module  will  build  the  following  structure. 


$DESCRIPTOR_CONFLICTS 
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‘ 2.4,30.7  Detailed  Design 


Each  resource  required  by  the  input  data  structure,  $SCHED_TINIT , 
must  be  checked  against  the  preceeding  resource  assignments  in  the 
standard  data  structure,  $RE SOURCE,  for  correspondence  of  both  inter- 
vals and  descriptors.  Failure  of  either  interval  or  descriptor  corres- 
pondence causes  a node  to  be  added  to  the  output  data  structure, 
$DESCRIPTOR_CONFLICTS.  If  the  resource  is  not  specified  by  name  then 
a resource  name  is  associated  with  that  resource.  Contingent  resource 
intervals  are  examined  only  when  necessary  and  requested  via  the  C0N_ 

CHECK  input. 

If  resource  descriptors  are  not  specified  in  the  input  data 
structure,  then  any  resource  of  the  proper  type  and  name  is  presumed 
acceptable,  and  the  first  one  found  is  selected.  For  required  re- 
sources which  are  not  identified  by  name,  the  descriptors  are  examined 
first.  Following  successful  correlation  of  descriptors,  the  intervals 
are  examined.  If  this  check  is  unsuccessful,  contingency  intervals 
are  examined,  if  requested. 

If  the  required  resource  name  has  been  specified,  the  intervals 
are  examined  first,  follox^ed,  if  successful  by  descriptor  examination. 

This  order  is  preferred  as  the  descriptor  examination  is  expected  to 
require  more  machine  time. 

When  the  job  to  be  inserted  has  been  compared  with  the  preceding 
assignments  it  is  compared  with  the  suceeding  assignments.  The  intervals 
are  examined  first,  followed  by  examination  of  the  descriptors. 

I 
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Internal  procedures  are  utilized  to  perform  the  functions  of 
descriptor  comparison,  interval  comparison  and  building  the  output 
data  structure, 

2,4,30,8  Interval  Variable  and  Tree  Name  Definition 
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$ASSIGN 

$ASSIGNMENT 

CHECK__FLAG 

$CURKENT_PROFILE 

$DESC 

DESCRIP_0K 

$DESCRIPTION 

$DESCRIPT0R_1 

$DESCRIPT0R_2 

$DESR 

$DUMMY 

$DUMMy_l 


Identifier  for  each  subnode  of  ASSIGNMENT 
for  the  resource  being  examined 

Pointer  for  the  ASSIGNMENT  node  in  inter- 
nal procedure  INTERVAL__CHECK 

Flag  in  internal  procedure,  DESCRIPjCHECK, 
set  to  'YES'  if  resource  descriptors  match, 
set  to  'NO'  if  they  do  not  match,  corres- 
ponds to  DESCRIPjOK 

Identifier  for  each  subnode  of  $PR0FILE  in 
internal  procedure,  INTERVAL_CHECK 

Identifier  for  each  subnode  of  last  set  of 

% 

FINAL  descriptors 

Flag  denoting  descriptor  matching,  corres- 
ponds to  CHECK_FLAG 

Identifier  for  each  subnode  of  $NAME  when 
checking  descriptors  with  following  jobs 

Identifier  in  internal  procedure,  BUILD_ 
CONFLICT,  for  descriptors  of  earlier  job 
to  be  added  to  output  data  structure, 
$DESCRIPT0R_C0NFLICTS 

As  $DESCRIPT0R_1,  for  later  job 

Identifier  for  each  subnode  of  first  set  of 
INITIAL  descriptors 

Temporary  storage  for  substructure  of  last 
subnode  of  $RES -STATE 

Single  node  tree,  whose  value  is  the  label 
of  $SCHED-UNIT,  used  in  call  to  internal 
procedure  BUILD_CONFLICT 


$DUMMy_2 


$DUMMY__3 

$FOLLOWING_JOB 

$FOUNDJSfAME 

lEND 

$IFLAG 

$INTERVALJDK 

ISTART 

$JOB__ID 

$KSTART 

$NAME 

$NAME__FOUND 

$NAME_MISSING 

$PR£CEDING_JOB 


- Single  node  tree,  whose  value  is  the  label 
of  $TYPE,  used  as  is  $DUMMY_1 

- Single  node  tree,  whose  value  is  the  label 
of  $NAME,  used  as  is  $DUMMY_1 

- Identifier  in  internal  procedure,  BUILD__ 
CONFLICT,  for  name  of  later  job  with  de- 
scriptor conflicts  to  be  added  to  output 
data  structure 

- Name  of  resource  returned  from  internal 
procedure  DESCRIP -CHECK,  whose  descriptors 
match 

- Numeric  value  of  JOB-INTERVAL  end  time 

- Flag  in  internal  procedure,  INTERVAL__CHECK, 
set  to  'YES'  if  job  intervals  correspond, 
set  to  'NO'  if  they  do  no to  Same  as 
$INTERVAL_OK 

- Flag  denoting  interval  agreement,  corres- 
ponds to  $IFLAG 

- Numeric  value  of  JOB-INTERVAL  start  time 

- Single  node  tree  whose  value  is  that  of 
the  last  identified  JOB-ID  in  $RES-STATE 

- Single  node  tree  whose  value  is  the  start 
time  of  the  schedule  interval  being  examined 

- Identifier  for  each  subnode  of  $TYPE 

- Identifier  in  internal  procedure,  DESCRIP_ 
CHECK,  for  each  subnode  of  $RESOURCE_TYPE 

- Flag  indicating  the  required  resource  name 
is  not  specified 

- Same  as  $FOLLOWING_JOB  for  earlier  job 
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^PROFILE 


$RES__NAME 

$RES__STATE 

$RES__TYPE 

$RESOURCE_NAME 

$RESOURCE_TYPE 

•$  STATE 

$START_TIME 
$ SUBNAME 
$TEMP_NAME 

$TREE 


- Identifier  in  internal  procedure,  INTERVAL_ 
CHECK  for  normal  or  contingency  subnodes  of 
INITIAL__PR0FILE  of  the  resource  being  exam- 
ined 

- Identifier  of  the  resource  name  substructure 
found  in  internal  procedure,  DESCRIP_CHECK, 
Corresponds  to  the  single  $FOUND__NAME  trans- 
mitted back  to  main  procedure „ 

- Descriptor  state  at  specified  time  returned 
from  internal  procedure,  DESCRIP^CHECK,  Cor- 

t 

responds  to  output  of  library  module, 
DESCRIPTOR_PROFILE . 

- Identifier  in  internal  procedure,  BUILD_ 

CONFLICT,  for  resource  type 

- Identifier  in  internal  procedure  DESCRIP_ 

CHECK  for  resource  name  substructure  being 
examined 

- Identifier  in  internal  procedure  DESCRIP_ 
CHECK  for  resource  type  substructure  being 
examined 

- Identifier  in  internal  procedure  DESCRIP_ 
CHECK  for  output  of  library  module, 
DESCRIPTOR_PR0FILE 

- Identifier  in  internal  procedure  DESCRIP__ 

CHECK  for  initial  time  of  job  to  be  inserted 

Identifier  of  each  subnode  of  $NAME  when 
checking  descriptors  of  preceding  jobs 

- Temporary  storage  for  the  resource  name  iden- 
ified  for  the  required  resource  with  name  not 
specified 

- Tree  whose  subnode  values  are  the  labels  of 
the  last  set  of  FINAL  descriptors 
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$TYPE 


Identifier  for  each  subnode  of  $RESOURCE 
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Modifications  to  Functional  Specifications  and/or  Standard 
Data  Structures  Assumed 


None 


2.4.30,10  Commented  Code 


C«ECK*DESCRIPTOR.GOMPATIBILITyI  procedure <$CCN^CHECKt$SCHED_UNlT# 
SRESOURCE#*OESCRlPTOR_CONFLICTSj  OPTIONS (EXTERNAL) I 

/* 

/•  THIS  MODULE  IDENTIFIES  INCOMPATIBILITIES  BETWEEN  RESOURCE 

/♦  DESCRIPTORS  ARISING  WHEN  A SINGLE  JOB  IS  TO  BE  INSvTRTfD  ON  A 
/#  TIMELINE  CONTAINING  JOBS  ALREADY  ASSIGNED, 


/* 

/•  INPUT* 

/• 

/• 

/* 

/• 

/* 

/* 

/* 

/* 

/* 

/#  OUTPUT; 

/* 


sscheo.unit  - The  job  to  be  Inserted,  .this  struc- 
ture HAS  THF  form  of  A SINGLE  NODE  OF  THE  STAN- 
DARD data  structure*  SSCHEDULE. 

SRESoURCE  THE  STANDARD  DATA  STRUCTURE  CONTAINING 
THE  resource  assignments. 

CON.CHECX  - indicates  WHETHER  CONTINGENT  RESOURCES 

are  TO  BE  Used,  with  item  specific  resources, 
THIS  means  the  use  OF  CONTINGENCY  INTERVALS. 
VALUFS  - »YrSt  use  contingency  intervals 

- »No  » DO  not  use  contingency  intervals 

soeScriptor«,conflicts  - A Tree  identifying  jobs  in 
conflict  and  the  resources  causing  the  conflict. 


/* 

declare  $TYPE*5NAME,$0ESCRIP.0K,JRFS>NAME*SINTERVAL.0K,SDESCRIPTI0N* 
SNAME1mISSIN6,$SUBNAME*  TSTART,  IEND.SKSTART* 
$ASSlGN*TEMPlTYPE,STEMPi»NAME,SRES»STATE  LOCAL? 
declare  SOUMMY* Sjoi.lD  LOCAL? 


/*  EACH  resource  MUST  BE  CHECKED  AGAINST  THE  ASSIGNMENTS  FOR 

/*  CORRESPONDENCE  OF  ROTH  INTERVALS  AND  DESCRIPTORS.  FAILURE  OF 
/*  EITHER  CAUSES  A SUBNODE  To  BE  CONSTRUCTED  ON  THE  tCONFLICT* 

/*  TREE.  IF  THE  RESOURCE  IS  NOT  IDENTIFIED  BY  NAME*  THEN  A NAME 
/#  IS  ASSOCIATED  WITH  THE  RESOURCE.  CONTINGENT  INTERVALS  ARE 
/•  examined  ONLY  WHEN  NECESSARY  AND  REQUESTED.  ASSIGNMENTS  ARE 
/*  CHECKED  PRIOR  TO  THE  TIME  THE  JOB  iS  TO  BE  INSERTED*  AND  THEN 
/•  FOR  TIMES  later  THAN  THE  JOB  IS  TO  BE  INSERTED. 

PRUNE  *DESCRIPT0R£C0NFLICTSI 

ISTART  = $SCHEO,_UNIT.JOB„INTEpVaL. START? 

lEND  = SSCHED^UNIT. JOBJINTERVALeENO? 

00  FOR  ALL  subnodes  OF  ESCHED'';UNlT. RESOURCE  USING  STYPE? 

DO  For  ALL  subnodes  of  STYpE  USING  SNAmE? 

IF  LABEL (SNAME)  = • * 

Then  do  for  all  subnoder  of  sname  using  ssubname? 

SKSTART  » SsUBNAME.INTFRVAL.STarT  * ISTART? 

SNAME«MISSING  s »YES»?  . 

CALL  DESCRlPlcHECK(5MAME‘fMlSSlN6,$SUBNAME*$RES0URCE.#LABEL ( 
STYPE) **KSTART*«DESCPIP10Ks 
SRES«NaME*SRESw^STATF)  ? 

IF  $0ESCRIP„0K  = »YES» 

THEN  Do? 

call  INTERVAL.CHECK($SUBNAmE»SRES0URCE.#LA8EL (STYPE) . 
#LABEL(SrES.NAME) .INITIAL«PR0FILE*N0RMAL* 
SRES0URCF.#LABEU(STYPE) «#LABEL($RES.NAME) • 


#/ 

*/ 

#/ 

#> 

»/ 

#/ 

*/ 

•/ 

#/ 

*/ 

»/ 

«/ 

*/ 

*/ 

*/ 


♦/ 

#/ 

*/ 

f/ 

*/ 

#/ 

»/ 

*/ 
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assignment. 
sinterval|ok) » 

TF  «INTERVAL_Ok  s »yes* 

THEN  STEMP.NAME  » LABEL ( SRES_NAME) I 

else  do» 

IF  $con«check  = *yes* 

^^^CaP'l*  INTERVAI CHECK  (SSUBNAME.SRESOURCE. 

i;LAB€L(iTYPE).#LABEL(SRES!LNAME). 
INITIAL^PROFILE.CONTINGENCY. 
$RESoyRCE.#LABEM$TYPE)  .#LABEL 

(SreslnamE) .assignment . 
sintervalIok) I 

IF  SINTFRV AL— 0*^  “ *YES* 

THEN  STEMP^NAME  = LABEL (SRES.NAME) I 

^*"$DUMMY1=LABEL(SSCHED_UNIT)  ^ 

5DUMMY2  = LABEL (STYPE) I 
SDUMMY3  * LABEL(SNAME) » 


IF 


SPESIsTATE(LAST) .job^id  identical 
TO  SNULL  then  DOi 
GRAET  SRES«STATE(LAST)  at  sdummyi 
SJOB' id  = SRES^STATE (LAST) . JOB^IOl 
graft  SOUMMY  at  S'  ES„STATE(NEXt) I 

ELSE  SjOB^IO  = SRES^STATE  (LAST)  , J0R«,IDI 

call  BUILD_C0NFLTCT($0UMMY1. 
SJOB^ID.SDUMMYS. 

SDUMMY3»SRES«STATE( 

LAST) .DESCRIPTOR.SSUBNAME. 
DESCRIPTOR(FIRST) .initial. 

SDFSCRIPTOR^CONFLICTS) I 
IF  SRES0URCE*#LAPEL ($TYPE) .^LABEL (SNAMp • 
accTGWmFNT (FIRST)  IDENTICAL  TO  SNULL 

THEN  PRUNE  SDEScRlPTOR£CONFLlCTS (LAST ) .RESOURCE. #LABFL 

(STYPE) •#LABEL(SNAME) .SCHED_DESCRIPT0R  I 

FND! 

ENOI 

ELSE  ^®*p|j^^Y^„l_^eEL.($SCHED_UNlT)  ; 

SDUMMY2  «■  LABEL (STYPE) I 
S0UMMY3  = label (SNAME)? 


IF 


$RES1sTATE(LAST) .job.id  identical 
TO  snull  then  00» 
graft  $RES_STATE(LAST)  at  SOUMi^Yl 
SJObIiD  s SRES„STATE(LAST) .job^idi 
graft  SDUMMY  at  $RES3TATE(NEXt)  I 

ends 
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ELSE  SJOB^ID  ■ SRES^STATE (LAST) , JOR—in I 


CALi‘  BUiLOl.CONFLlCT(SOUMMYl  * 

SjOB«ID.$DUMMY2t  . . 

SDUMMY3t$RES.STATE {LAST) •descriptor* 


SSUBNAME. descriptor (FIRST). initial* 
SDESCRIPTOR^CONFLICTS) I 
IF  $ReSOURCE.ALAbEL(STYPH) •ALABEL(SNAME) . 

ASSI6NMENT  (FIRST)  IDENTICAL  TO  SNULL  , 

then  prune  $dEScRIPTOR«CONFLICTS(LAST) •resource.#labfl 
(STYPE) .ALABEL(*NAME) ,SCHEO_DESCRlPTOR  I 

END< 

END  I 


END  I 

ELSE  DO! 


SDUMMYlsLABEL(SSCHED^UNlT)  I 
SDUMMY?  b LABEL (STYPE) I 
SOUMMY3  B LABEL (SNAME) I 


IF  SRESIsTATE(LAST) •UOB^ID  IDENTICAL 
TO  SNULL  THEN  DOI 
graft  $RES_STATE(LAST)  at  $0UMJ4Y* 
SJOB'iD  * SRES.STATE(LAST) .job^idi 
graft  SDUHMY  at  S ES.STATE(NEXT) I 


graft  SDuMMY  at  $RES„STATE(NEXT) » 

ENOI  ^ - - 

ELSE  SJOB.ID  s $RES.STATE(LAST) .JOP^lni 


Call  ruild.conflict(i;dummyi*  « ^ 

$JOR.ID*SDuMMY2,SDUMMY3*  $RES_STATE(LAST) . 

descriptor *SSUBNAME.DEScRIPTOR(FIRSTT, INITIAL* 

SDESCRIPTOR?^CONFLICTS)  I 

IF  SRES0URCE.#LAREL(STYPE) .ALABEL(SNAME) . 

assignment (FIRST)  identical  to  SNULL 

THEN  PRUNE  SOESrRIPTOR.CONFLICTS (LAST) .RESOURCE-ALARFL 
(STYPE) .#LABEl (SNAME) ,SCHED_DESCRIPT0R  I 

END* 

ELSE^^DO  FOR  ALL  SUBNODES  OF  SNAME  UPlNG  SSUBNAMEI 
SKSTART  . SSUBNAME.INTfRVAL. start  ♦ ISTARTI 

*CALl"inTErVAl1cHFCK(sSUBNAME*SRESOURCE,#LABEL (STYPE) .#LABfL 
(SNaME) , INI T I Al.PROFILE. normal *$RESOURCE, 

#LABEL($TYPE) .#LABEL(5NAME) .ASSIGNMENT  * 

SINTERVAL^OK) » 

IF  S1NTERVAL1.0K  ■ »YfS» 

THEN  DOI 

CALL  DESCRIP.ChECK(SNAME-MISSING*5NAME* 

LABEL(STyPE) *SKSTAPT* 
$DESCRIP.0K*$RES.NAME*$RES_STATE) I 


SRESOURCE.'#' 
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IF  *DESCRIP-0K  « »YFS» 
THENI 
ELSE  DO I 


SDUMMY1»LABEL(SSCHED.UNIT) I 
SDUMMY3  ■ LABEL (SNAME) I 
*DUMMY2  » LABEL(STYPE) I 


IF 


SRES'sTATE(LAST) •UOB.ID  IDENTICAL 
TO  SNULL  then  DOI 
graft  $RES_ST ate (LAST)  AT  SDUMmYi 
SJOBllD  « SRES«STATE(LAST) .JOB^ine 
GRAFT  SDUMMY  AT  SRES^STATF (NEXT ) » 

ENDI  , , „ 

ELSE  SJOB..ID  * 5RES_STATE  (LAST ) , JOB—Ini 

CALL  BuILDICONFlICT (SDUMMYI* 

SJOB  ID*$DUMMY2*$DUMMY3, 
SRES^STATE(LAST). descriptor. SSUBNAMF.  . . 
descriptor (FIRST) •INITIAL*SDESCRIPTOR«COnFLTCTS) 

» 

IF  SReSOURCE*#LAbEL($TYPE) .#LABEL(SNAME) • 
assignment (FIRST)  IDENTICAL  TO  SNULL 
Then  prune  SnESrRIPTOR.CONFLICTS(LAST) .resource. #LABFL 
(STYPE) .#La8El (SNAME) .SCHED.DESCRIPTOR  I 
ENDl 
ENDI 

else  Dot  , 

IF  SCON- CHECK  s »YES» 

CALL  intfrval* check (SSUBNAME*$RES0URCE.#LABEL ( 
STyPE).^LABEL(SNAME).INITIAL_PROFILE. 
CONTINGFNCYf SRES0URCE.#LABEL (STYPE) • 

#La8EL (SNAME) .ASSIGNMENT*SINTERVAL«0K)  I 

IF  sintervalIok  « *YES» 

CAi  L DESCRIP—CHECK ($NAME^MISSING*SSUBNAmE* 
$RES0URCE.#LABEL (STYPE) * 

SKSTART.SDESCRIP^OK* 
SRESI^AME.SRES.STATE) » 

IF  SDESCRIPlOX  * *YES» 

THENI 
FLSE  DOI 

$DUMMY1=LABEL(SSCHED_UNIT) I 
SDUMMY2  = label (STYPE) I 
SDUMMY3  * LABEL(SNAME) I 


IF 


SRES'sTATE (LAST) .JOB.IO  IDENTICAL 
TO  SNULL  THEN  DOI 
graft  SRES-ST ate  (LAST)  AT  SDUMJ^YI 
SJOB'iD  = SRES^STATE(lAST) .JOBflDl 
graft  SDUMMY  at  S ES.STATE (NEXT) I 
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END? 

ELSE  SJOB^ID 


a $RES„STATE(LAST)  .JOR-lr>l 


CALL  BUILD^CONFLICT (SDUMMYl » 

SJ0B.ID» 

5DUMMY2*SDUMMY3*SRES„, STATE ( 

LAST) *DESCRIPTOR*SSUBnAME* 
OESCRIPTOR(FIRST) .INITIAL* 
SDESCRIPTOR..CONFLICTS)  I 
IF  fRESOURCE.#LAREL(STYPE) .ALABEL (SNAME) • 

assignment (FIRST)  IDENTICAL  TO  SNULL  ^ ^ 

then  prune  SDEScRIPTOR^CONFLICTS (LAST) .RES0URCE«(#LABFL' 
($TYPE).#LA8EL(SNAME).SCHED^DESCRIPT0R  f 

FNOI 

ENpl 

ELSE  noi 

SDUMMYIsjLABEL  ( SSCHED^UNIT)  I 

SDUMMY2  * LAaEL(STYPE) « 

SDUMMY3  = label (SNAME) I 


IF 


SRES'sTATE(LAST) .job^id  identical 
TO  SNULL  THEN  DO? 
graft  SRES  STATE(LAST)  at  sdum^y? 
SJOBIiD  « SRES^STATE(LAST) .JOB^IOI 
GRAFT  SOuMMY  AT  SRES^STATF (NEXT ) t 

end?  , ^ 

ELSE  SjOB^lO  = SRES„STATE  (LAST ) . JOR«.ini 

call  BUIL0-C0NFLICT($0UMMY1# 

$J0B_ID*$0UMMY2* 

SDUMMY3»$RES.STATE(i.AST)  .DESCRlPTORf 
SSUBNAME.DESoRIPTOR (FIRST) .initial* 
JDESCRIPTOR^CONFLICTS) ? 

IF  SRESOURCE.ALArEL(STYPE)  .^?LABEL(1;NAME)  . 

ASSIGNMENT(FIpST)  identical  to  SNULL 
THEN  prune  $DESrRIPTOR_CONFLlCTS(LAST)»RESOURCEo^?LARFU 

(STYPE) .AUaBEl (SNAME) .SCHED_OESCRlPTOR  ? 

END? 

END? 

ELSE  00?^  qe5CR1ptor1pRofile($resource.alabeu(stypE)  .■ 
#LABEl{$NAME)  *sRESOURCE.(#LABEL(STYPE)  .a 
label (INAME) .ASSIGNMENT9SRES_STATE» 

SKSTART)?  . 

$0UMMY1*LABEL(SSCHED_UNIT) ? 

SDUMMYE  - LABELCSTYPE) I 
S0UMMY3  = label (SNAME) I 


IF 


SRESIsTATE (LAST) .J0B„10  IDENTICAL 
TO  SNULL  then  DO  I 
graft  SRES„STATE(LAST)  at  SOUMMY? 
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$JOb!^ID  = $RES«STATE(LAST>  •JObIidi 
graft  5DUMMY  AT  SRES^STATE (NEXT) I 
END* 

ELSE  SJOB.ID  = $RES_STATE(LAST) .JOR-IDI 


CALL  BUtLD„CONFLICT($DUMMYIp 

$J0B_I0»$DUMMY2*$DUMMY3* 

SRES.STaTeTlaST) .OESCRIPTORsSSUBNAME. descriptor 
(FIRST)  ;INITIAL*SDESCRI,pTOR«CONFLTCTS)  I 
IF  *ReSOURCE.#LAbEL{STYPE) .#LABEL($NAME) • 
assignment (FIRST)  IDENTICAL  TO  SNULL 
Then  prune  sdescriptor„conflicts(last) .resource*#larel 
(STYPE)  .^^LABEL  (SNAME)  ,sched_descriptor  ? 

END* 


END* 

end* 

/*  THIS  section  of  CODE 

/♦  times  later  than  the  job 
check.following1jobs  t 
DO  for  all  subnooes  of 


does  the 

IS  TO  BE 


checking 

INSERTED 


OF  assignments  at 


#/ 


sname  using  ^description* 


IF  SNAME^mISSING  = «YES» 
then* 

ELSE  $TEMP_NAME  = LApEL ( $NAME ) ? ^ ^ 

DO  FOR  ALL  SURNODES  oF  SRESOURCE.i^LABEL (STYPE) (STEMP^NAME) 

.assignment  using  sassign? 

if  sassign. INTERVAL.START  < (SDESCRIPTION.INTERVAL.END  ♦ 
ISTART) 

THEN* 

ELSE  DO* 

IF  ($DESCRIPTION,OESCRIPTOR(LAST) .FINAL  SUBSET  OF 

*ASSl6N.nESCRlPT0R<FlRST) .INITIAL  I SASSlGN.  . . 

DESCRIPToR(FIRST) .INITIAL  SUBSET  OF  SDESCRIPTTON. 
OESCRlPToR(LAST) .FINAL)  THEN* 

ELSE  DO* 

PRUNE  STRfE*  ^ 

DO  FOR  all  SUbNODES  OF  SDESCRIPTION. DESCRIPTOR 
(LAST). FINAL  USING  SDESC* 

STREE(nEXT)  = LABEL(SDESC) * 

DO  FOR  all'  SUBNODES  of  SASSIGN. DESCRIPTOR  (FIRST)  . 

initial  using  $oesr* 

IF  label (sdesr)  «<element  of  stree  then* 

ELSE  IF  $aSSIGNoDESCRIPT0R(F1RST) .INITIAL 
-,SJBSET  OF  sdescription. 
DESCrIPTOR(LAST) .FINAL 

then  do? 

$DUMMY1*LABEL(SSCHED_UNIT) * 

S0UMMY2  = label (STYPE) * 

$DUMMY3  = LABEL (SNAME)* 

CALL  aUli'olCONFLlCT (SASSIGN. JOB^IDf 
$0UMMY1«S0UMMY29$0UMMY3. 
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$ASSl6N.0E$CRlPt0R(FlRST) .INITIAL* 

$DESCRIPTI0^*DESCRIPT0R (LAST) .FINAL* 
$DfSCRIPTOr|COwFLICTS) I 
IF  SRES0URCE.#LABEL(STYPE)  .*^LABEL(*NAME)  • 
assignment (FIRST)  IDENTICAL  TO  SNULL 
them  prune  $DEScRIPTOR_CONFLICTS(LAST) .resource. #labfl 
(STYPE).#LABEl($NAME).SCHEO^DESCRIPTOR  I 
GO  TO  NExtIrESOURCE.NAMEI 
END  I 
END  I 
ENOI 

END  I 

IF  SDESCRIPTOR«CONFLlCTS (FIRST)  IDENTICAL  TO  SNULL 
THEN  LABEL (SNAME)  = STEMP^NAMEI 

end  I 

NI  XT.RESOURCE^NAME  * 

END  I 
ENDI 


/♦ 

/• 

/♦ 

/• 

/* 

/* 

/* 

/* 


OESCRIP  CHECK*  procedure (SNAMF^MISSING. 5PES0URCE.NAME*SRES0URCE_TYPE* 
SSTART  TIME**CHECK_FlAG,$FOUND.NAME,$STATEM  ^ 

this'inteRnal  procedure  is  designed  to  check  only  the 

RESOURCE  descriptors,  this  PROCEDURE  THE 

• descriptor  profile*  to  Determine  the  resource  J ^ 

TTMF  THE  JOB  IS  TO  BE  iNSpRTED.  THE  FINAL  DESCRIPTORS  OF  THE 
RESOURCE  state  ARE  COMPARFD  WITH  THOSE  REQUIRED  BY  THE  JOB  TO 
Br  INSERTED.  THE  INPUT  VARIABLE  .nAME.MISSING*  INFORMS  THE 
?HO«DURE  TO  return  A RESOURCE  NAME  IF  MATCHIN8  DESCRIPTORS 

declare  1RES0URCE_NAME • $RESOUpCE_TTPE  > *ST ART_T IME  » CHECK_FL AG» 
SNAME.FOUND  * SSTATE  * SNAMF-MI SS ING  LOCAL  I 

$check«flag”=  »N0’I 

THEN^Do'FO^AL^Su|NODES  OF  SRESOUrcE.TYPE  UJING  *N*«|-FOUNOi 
call  DESCRIPTOR  PROFILE (SNAME^FOUNO.SNAME^FOUND.ASSlGNMENTt 
$STATE*SSTaRT^TIME) I ■ , . 

SRESOURCE'nAME  .DESCRIPTOR(FIRST). INITIAL  SUBSET  OF 

SSTATE (LAST) .DESCRIPTOR 
THEN  DOI 

$CHECK.^LAG  * •YES»f^ 

SFOUNDiiNAME  « SNAmE_FOUND| 

return! 

ENDI 

ENDI 

^'■*CALl*DESCRIPTOR' PROFILE  ($RESOURCE_TYPE.«LABEL  ($RESOURCE_NAME).t 

f RESOURCE.TYPE . «LABEL ( SRESOURCE^NAMEI . ASS IGNMENT . 

SSTATEfSSTART^TlMF)  I 

IF  $RESOURCE£nAME(FIRST).DESCRIPTOR(FIRST). INITIAL  SUBSET  OF 


*/ 

*/ 

#/ 

*/ 

»/ 
#/ 
»/ 
• / 


IF 
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SSTaTE<LAST) .descriptor 
then  001 

SCHECK-FLAG  = ’YESM 

sfounoIname  * SRESOURCELnamE* 

RETURNI 

ENOI 

END» 

EN0»0ESCRIP„CHECK«  ENOI 


INTERVAL.CHECKI  PRoCEOURE (SREs0URCFL.NAME*$PR0FILE*SASS16NmENT*SIfLa®) I _ 
/*  THIS  INTERNAL  PROCEDURE  CHECKS  THE  INITIAL  PROFILE  OF  THE  */ 

/•  PROPER  RESOURCE  TYPE  AND  MAME  TO  INSURE  THAT  THE  RESOURCE  IS  ♦/ 
/*  AT  LEAST  potentially  AVAIlABL^  AT  THE  TIMES  REQUESTED,  #/ 

declare  $!FLAGf$PR0FlLFt$RES0uRCE_jNAME*SASSIGN  LOCALI 
SIFLAG  = »YES*  I 

DO  FOR  ALL  SUBNoDES  OF  SPRoFlLE  USIN®  HCURRENT.PROFILE I 
IF  SRESOURCE  NAME, INTERVAL .START  ♦ ISTART  >=  SCURRENT|PR0FILE, 
START  & SRESoURCE^NAME. interval, END  ♦ISTART  <»  $CURRENT«PR0FTLE . 
END 

then  GO  To  NeXTIsCHEO.ImTERVALI 
END! 

SIFLAG  a »N0»| 

next^scheoIinterval: 

IF  $lFLAGa»YESt 

THEN  DOI 

DO  FOR  ALL  SUbNODES  OF  SaSSiGNMENT  UciNG  SASSIGNI 
IF  SRESOUReE-NAME. Interval, START*ISTART<aSASSIGN, 

INTERVAL, START 

THEN  IF  SRESOURCE  NAME, INTERVAL, END+ISTARToSASSIGN, INTERVAL. 
START 

THENI 

ELSE  SiFLAGa’NOM 
ELSE! 

ENOI 

ENOI 

ENOI  /*  end1interval_check  */ 

BUILD_C0NFLICT;  procedure ($PRFCEDING_J0B*%F0LL0WING_J08,SRESiiTYpE, 
$RESlNAME#SDESCRIPTORlltSOESCRlPTOR«2,SOESCRIPTOR.CONFLlCTS) I 

/♦  This  procedure  constructs  ThlE  OUTPUTt  »sdescriptor.conflicTs»  */ 

DECLARE  SPRECEDlNSi'UOBtSFOLLOwlNGijOBfSPRECEDING.DESCRIPTORf 
$FOLLOWING«DESCRlPTOR  LOCAlI, 

SOESCRIPTOR^CONFLIcTS (NEXT) .JobIio (FIRST) = SFOLLOW ING^JOB I 
label {$DESCRIPTOR.CONflICTS(LaST) .JOBIiD (FIRST) ) « t*! 
SDESCRIPTOR_CONFLIcTS(LAST) ,Job1I0(NEXT)  » SPRECEDING^JOBI 
label {S0ESCRIPT0R.CONFLICTS (LAST) .JOB JD (LAST) j a »i| 
SDESCRlPTOR_CONFLlCTS(LAST) .RESOURCE.# (SRES^TYPE) .# ( SRES.NAME) • 
SCHED^OESCRIPTOR  s SOEScRIPTOR.il 
sDescriptor_conflicts(last) .Resource.# (Sres.type).#(sres.name) • 
JOB.DESCRIPT0R  * SDESCRtPTOR^E! 


ENOI  /#  BUILD-CONFLICT  */ 

ENOI  /«  CHECK-DESCRIPT0R_C0MPATIBILITY  #/ 
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2.4.31  ORDER_BY_PREDECESSORS 
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ORDER_BY_PREDECESSORS 
2.4.31.1  Purpose  and  Scope 

Given  a set  of  activities  and  events  and  their  respective 
predecessor  sets,  this  module  either  places  them  in  a technologi- 
cal order  if  one  exists  or  identifies  a subset  of  the  activities 
containing  a cycle.  A technological  ordering  of  the  events  and 
activities  means  an  ordering  ,such  that  any  activity  or  event  is 
preceded  by  all  of  its  predecessors  or  equivalently  followed  by 
aqq  of  its  successors.  A cycle,  on  the  other  hand,  is  a chain 
of  predecessor— successor  related  activities  or  events  implying 
that  some  event  or  activity  is  a predecessor  of  itself.  Such  an 
activity  or  event  could  never  be  scheduled  because  one  of  its 
predecessors,  namely  itself,  could  never  be  completed  beforehand. 
Hence,  the  presence  of  cycles  in  a precedence  network  precludes 
any  scheduling  or  critical  path  analyses. 

2.4.31.2  Modules  Called 
None 
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2.4.31.3  Module  Input 

Network  definition  C$JOBLIST)  - activities  or  events  (first 
level  subnodes)  are  not  technologically  ordered. 

i 

$J0BLIST 


VALUE)  (VALUE) 
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2 . A . 31 . 4 Module  Output 

1)  Network  definition  ($JOBLIST)  - activities  or  events  (second- 
level  subnodes)  are  technologically  ordered. 

2)  Subset  of  jobs  containing  cycles  (if  any  exist)  ($CYCLE_SET) 


$CYCLE_SET 


It  can  be  shown  that  the  activities  and  events  of  a project 
can  be  technologically  ordered  if,  and  only  if,  the  precedence 
relations  contain  no  cycles.  It  must  be  noted,  however,  that  if 
cycles  are  absent,  the  technological  ordering  is  by  no  means 
unique.  The  particular  ordering  produced  by  this  module  results 
from  inductively  "scheduling"  in  cycles  all  those  activities  or 
events  whose  predecessors  are  "scheduled."  Eventually  a cycle 
arises  where  there  are  no  activities  or  events  with  all  of  their 
predecessors  "scheduled."  If  some  activities  or  events  remain 
unscheduled,  they  contain  a cycle.  A more  precise  description 
of  the  logic  of  the  module  is  provided  in  the  functional  block 
diagram. 
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2.4.31.6  Functional  Block  Diagram 
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2.4.31.7  Typical  Application 


The  module  is  applied  wherever  a job  set  must  be  technolog- 
ically ordered  or  wherever  erroneous  definition  of  the  network 
may  result  in  cycles  that  would  invalidate  further  analysis . 
Examples  of  the  former  include  the  modules  CRITICAL_PATH__CALCULATOR 
and  REDUNDANT_PREDECESSOR_CHECKER.  An  example  of  the  latter  is 
the  HEURISTIC_SCHEDULING_PRECESSOR. 

2.4.31.8  Reference 

Muth,  John  F.  and  Gerald  L.  Thompson,  Industrial  Scheduling ^ 
Prentice  Hall  Inc.,  Englewood  Cliffs,  New  Jersey,  1963. 
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2.4.31.9  DETAILED  DESIGN 


During  the  implementation  of  this  module,  it  was  determined  that  a 
restart  capability  could  be  added  with  very  little  extra  logic.  Since 
this  provides  an  important  service  to  the  user,  it  has  been  incorporated 
in  the  code  presented  here. 

The  module  repeatedly  searches  through  the  list  of  jobs  until  it 
finds  one  whose  predecessors  are  already  in  the  technologically  ordered 
list.  This  job  is  then  transferred  to  the  ordered  list.  This  iterative 
process  continues  until  all  of  the  jobs  have  been  ordered  or  until  a 
cycle  is  detected  in  the  remaining  set  of  jobs. 

The  calling  program  should  always  check  to  make  sure  that  $JOBLIST. 
FIRST  is  identical  to  $NULL  before  assuming  that  $ORDERED_LIST  contains 
the  complete  set  of  jobs.  If  there  are  any  jobs  left  in  $JOBLIST  after 
calling  ORDER_BY_PREDEGESSORS,  the  user  can  assume  that  they  contain  an 
input  error. 

2.4.3i!i0  INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 

^jOB  - Used  to  reference  a subnode  of  $ORDERED_LIST 

$JOBLIST  - Is  the  set  of  unordered  jobs  input  by  the  calling  program 

$NAME  LIST  - Used  to  record  the  names  of  jobs  that  have  already  been 

ordered 

$ORDERED  LIST  - Is  the  set  of  jobs  that  are  technilogically  ordered 
$TEMP  - Is  a temporary  storage  area 
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ORDER  BY  PREDECESSORS 


^ Enter  ^ 




Record  the  names  of  all  the  jobs 
already  contained  in  the  ordered  list. 

7 

j 

No 

7 

Find  the  first  job  in  the  job  list  whose 
predecessors  have  already  been  ordered. 

5 

7 

Transfer  this  job  Into  the  ordered 
list  and  record  its  name. 


A cycle  has 
been  detected. 
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2.4.31.11  MODIFICATIONS  TO  FUNCTIONAL  SPECS  AND/OR  STANDARD  DATA  STRUCIIIRES 


The  functional  definitions  of  the  input  and  output  parameters  of  this 
module  have  been  changed.  This  was  done  to  provide  the  user  the  ability  to 
restart  the  ordering  process  by  inputting  an  already-ordered  list  of  jobs.  ' 
The  unordered  jobs  will  then  be  added  to  this  list. 

If  the  user  is  working  with  large  precedence  networks,  it  is  possible 
that  his  original  specification  of  the  network  will  contain  several  cycles. 
ORDER_BY_^PREDECESSORS  will  identify  these  cycles  (one  per  call)  and  also 
return  a partially  ordered  list  of  jobs.  Once  the  cycle  has  been  eliminated, 
the  user  will  need  to  call  ORDER_BY_PREDECESSORS  again.  However,  the  jobs 
that  were  returned  in  the  ordered  list  may  be  predecessors  of  those  returned 
in  $GYCLE_S'ET.  If  this  module  were  implemented  as  originally  specified, 
the  above  fact  would  force  the  user  to  recombine  the  ordered  and  unordered 
jobs,  before  calling  the  module  again.  This  means  that  after  detection  and 
elimination  of  each  cycle.^  ordering  of  the  entire  set  of  jobs  would  have 
to  be  reattempted.  Iii  order  to  avoid  this  cumberscme  and  wasteful  process, 
a restart  capability  has  been  provided. 

$JOBLIST  is  still  used  to  input  the  list  of  unordered  jobs,  but  is 
not  used  to  return  the  list  of  ordered  jobs.  The  general  philosophy  of 
the  module  is  that  as  the  jobs  are  ordered,  they  are  transferred  from 
$JOBLIST  to  the  output  tree,  $ORDERED_LI-ST . This  means  that  if  a cycle 
is  detected,  the  set  of  jobs  containing  the  cycle  will  be  returned  in 
$ JOBLIST , thus  eliminating  the  need  for  $CYCLE_SET.  This  approach  pro- 
vides the  restart  capability  by  allowing  the  user  to  input  an  already- 
ordered  set  of  jobs  (in  $ORDERED_LIST)  onto  which  the  jobs  in  $JOBLIST 
will  be  added. 
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The  functions  of  $JOBLIST  and  $ORDERED_LIST  are  clearly  separated. 
For  purposes  of  both  input  and  output,  they  will  contain  unordered  and 
ordered  lists  of  jobs,  respectively. 

2.4.31.12  COMMENTED  CODE 


0R0ER_BY.PREDECESS0RS:  procedure  (SJOBLIST,  SORDERED.LIST) 

OPTIONS(EXTERNaL) » 

/*  ;> 

/♦  THIS  MODULE  technologically  ORDERS  THE  SET  OF  JOBS  INPUT  IN  i> 

/*  sjORLisT  and  Returns  them  in  sordfrediilist.  sordered.list  can  #> 

BE  USED  TO  input  AN  ALREAdY-ORDERED  SET  OF  JOBS  ONTO  WHICH  THE  #/ 

/*  JOBS  contained  IN  SJOBLISt  ARE  TO  BE  ADDED,  IF  A CYCLE  IS  DE-  ♦/ 

/♦  TeCTED  IN  The  precedence  NETWORKt  the  subset  OF  JOBS  containing  ♦/ 

/*  THE  CYCLE  IS  RETURNED  IN  SJOBlIST,  #/ 

/* 

declare  SNAMf^LIST*«JOB*STfMP  local  » 
do  for  all  subnodes  of  sordered’list  using  SJOB  I 
insert  LABEL(SJOB)  before  SNAMEIlIST (FIRST)  I 
End  I 

DO  WhILE(SJOBLIST (FIRST)  NoT  IDENTICAL  TO  SNULL)  i 

graft  SJOBLIST (FIRST) SElEMEnT.TEMPORAl^RELATION, PREDECESSOR 

SUBSET  OF  SNAME.LIST)  AT  sfpMP  | 
IF  STEMP  identical  TO  SnULL  THEN  RETURN  I 
«NAME..LIST(NEXT)  = LABEi  (STEMP)  | 

GRAFT  STEMP  at  SORDERED^LIST (NEXT)  I 
END  I 

END?  /*  ORDFRIbyIpREDECEsSORS  «/ 
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2.4.32  RESOURCE_ALLOCATOR 


V 


.4.32  RESOURCE  ALLOCATOR 


2.4.32  RESOURCE_ALLOCATOR 

2.4.32.1  Purpose  and  Scope 

This  module  allocates  resources  to  the  various  activities  in 
a project  to  produce  a schedule  that  satisfies  all  the  resource 
constraints  and  heuristically  minimizes  the  project’s  duration. 
What  precisely  is  meant  by  a project  is  detailed  in  the  purpose 
and  scope  section  of  the  executive  module  HEURISTIC_SCHEDULIN6_ 

PROCESSOR. 

The  scheduling  heuristic  takes  a very  pragmatic  approach  to 
the  problem.  It  realistically  assumes  that  the  resource  con- 
straints are  "soft."  For  example,  additional  labor  or  equipment 
can  frequently  be  obtained  by  subcontracting  or  scheduling  over- 
time. Further,  within  narrow  limits  resources  can  virtually  be 
expanded  by  increasing  the  pace  of  the  effort.  To  model  the 
softness  of  the  resource  constraints,  contingency  threshold  incre- 
ments to  the  normal  availability  levels  of  critical  resources  are 
' specified  by  the  user.  Then,  whenever  an  activity  cannot  be 
scheduled  by  its  critical  path  late  start  time,  the  current 
partial  schedule  is  voided  beyond  the  time  that  the  resource- 
bound  activity  first  had  all  of  its  predecessors  completed.  From 
that  point  onward,  the  schedule  is  rebuilt  assuming  that  all  of 
the  critical  resources  that  previously  prevented  scheduling  are 
now  available  at  their  respective  original  normal  levels  plus 
their  respective  contingency  threshold  increments.  When  the 
previously  resource-bound  activity  is  finally  scheduled  Che  pool 
levels  of  its  critical  resources  are  returned  to  their  normal 
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levels  (assuming  the  contingency  increments  are  not  simul- 
taneously required  for  some  other  resource— bound  activity). 

The  normal  scheduling  heuristic  is  a time  progressive  pro- 
cedure employing  the  critical  path  late  start  time  of  each 
activity  as  a dynamic  priority ' rule . Fortunately,  the  late-suart 
date  of  an  activity  does  not  depend  on  the  actual  start  dates  of 
its  predecessors  provided  none  of  these  is  delayed  beyond  its 
late  start  date.  If  some  activity  is  delayed  beyond  its  late 
start  date  by  an  interval  "a,"  the  project  completion  date  is 
slipped  by  "a"  time  units  and,  hence,  the  late  starts  of  any 
activity  with  respect  to  any  other  is  unaltered.  Hence,  the 
priority  function  does  not  require  updating  each  time  a new 
activity  is  added  to  the  partial  schedule.  The  procedure 
basically  steps  through  process  time  scheduling  those 
activities  whose  predecessors  have  all  been  completed  in  order 
of  their  late-start  priority  and  within  the  existing  resource 
availabilities.  The  contingency  resource  increments  and  the 
associated  rescheduling  can  be  viewed  as  a modifying  heuristic 
on  the  earliest  late-start  date  priority  rule. 

The  RES0URCE_ALL0CAT0R  serves  as  the  forward-pass  segment  of 
the  combined  forward-  and  backward— pass  heuristic  resource  allo- 
cating procedure  called  the  HEURISTIC_SCHEDULING_PR0CESS0R . It 
produces  a tentative  front-loaded  resource  allocation  together 
witli  its  associated  practical  estimate  of  the  project  duration. 
Preserving  this  estimated  minimui.i  project  duration,  the  RESOURCE 
LEVELER  delays  activities  in  the  tentative  schedule  within  the 
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limits  of  their  residual  slack  to  produce  heuristically  the  most 
level  resource-loaded  schedule. 
lA.yi.1  Modules  Called 
None 

2.4.32.3  Module  Input  • 

1)  Network,  Critical  Path  Data  and  Activity  or  Event  Definitions 

$J0BSET 
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2.4.32.4  Module  Output 


1)  Resulting' Heuristic  Schedule  ($SCHEDULE) 


$SCHEDULE 


2)  Revised  Resource  Profile  Including  Usage  ($PR0FILES) 


$PR0F1LES 
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2.4.32.5  Functional  Description 

The  RES0URCE_ALL0CAT0R  uses  the  policy  of  scheduling  actxvxties 

as  soon  after  their  predecessors  are  completed  as  resources  be- 
come available  and  their  priority  warrants.  Ca,tegorxcally , 
scheduling  activities  as  soon  as  possible  does  indeed  tend  to 
produce  minimum  duration  projects,  but  only  at  the  expense  of 
heavily  front  loaded  resource  utilization  profiles.  Unfortunately, 
however,  it  is  usually  desirable  for  reasons  of  economy  to  utilize 
resources  at  as  constant  a rate  as  possible.  To  achxeve  level 
resource  utilization,  the  resulting  schedule  from  the  RES0URCE_ 
ALLOCATOR  is  passed  to  the  RESOURCE_LEVELER  module.  This  routine 
delays  jobs  within  their  residual  float  to  level  out  resource 
utilization  while  maintaining  the  project  duration  of  the  orxgxnal 

schedule. 

The  scheduler  tends  to  think  chronologically  beginning 
with  the  project  start  date.  Hence,  in  imitating  him,  it  is 
natural  to  use  a time  progressive  heuristic.  On  any  given  day  in 
his  chronological  scheduling  effort,  the  next  activxty  to  be 
scheduled  is  that  job  whose  predecessors  are  all  complete  and 
that  is  most  likely  to  be  slipped  beyond  its  late-start  date. 

Only  the  resource  constraints  can  cause  an  activity  to  be  so 
slipped  because  the  precedence  constraints  are  automatxcally 
satisfied  by  the  set  of  critical-path  early-start  txmes  for  the 
resource-unconstrained  situation.  Nevertheless  the  xnteractxon 
of  the  resource  constraints  with  the  precedence  constraints  can 
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be  extremely  complicated.  For  example,  a set  of  minor  delays 
occasioned  by  various  resource  constraints  can  accumulate 
sufficiently  over  the  precedence  network  to  slip  a subsequent 
activity  beyond  its  late  start  time  and,  hence,  delay  the  pro- 
ject. Modeling  the  resource  constraints  in  the  heuristic  pro- 
cedure is,  therefore,  extremely  difficult.  It  has  been  attempted 
by  several  investigators  but  the  results  have  never  justified  the 
complications.  Thus  the  most  reasonable  approach  appears  to  be 
resource  bound.  In  this  case,  then,  the  most  likely  precedence— 
constraint-free  candidate  for  slipping  the  project  completion  is 
that  activity  among  those  with  completed  predecessors  that  has 
the  earliest  late-start  date. 

Finally,  if  the  same  activity  does  slip  its  late-start  date 
thereby  delaying  project  completion,  the  scheduler  considers 
enacting  contingency  measures  such  as  obtaining  more  labor  and 
equipment  through  subcontracting  or  scheduling  overtime.  The 
heuristic  allocator  takes  the  same  approach,  adding  contingency 
threshold  increments  to  the  critical  resource  pools,  binding  the 
tardy  activity  beginning  at  the  time  its  predecessors  were  first 
completed,  the  rescheduling  the  entire  project  from  that  point 
onward . When  the  resource-bouird  activity  is  finally  successfully 
scheduled,  the  pool  levels  of  the  critical  resources  are  returned 
to  their  normal  values . 
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2.4.32.6  Functional  Block  Diagram 
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ORIGINAL  PAGE  IS 
OP  POOR  QUALITY 
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P fOOB  QOAta* 
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2. A. 32-12 


2.4.32-13 


Replace  current  just-completed  | 
activity  with  next  such  activity.! 


current  just-\s^ 
completed  activity 
.^h^e  any  successor^ 


Do  any 
unconsidered 
elements  remain 
in  just-completed 
'^et  of  activities/ 


Initialize  current  successor 
to  first  successor  of  current 
just-completed  activity 


Replace  current  successor 
with  next  successor  of 
current  just-completed 
activi ty . 


^-^o  any 
unexamined 

^/'successors  of  current' 
just  completed 
^N^^ivity  remain/^ 
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2.4.32.7  Typical  Application 


The  forward-pass  RES0URCE_ALL0CAT0R  module  can  be  used  in 
conjunction  with  the  backward-pass  RESOURCE_LEVELER  wherever  a 
short  duration  and  level-resource  profile  schedule  for  a project 
is  desired.  The  heuristics  involved  are  sophisticated  enough  to 
give  a practical  schedule,  but  simple  enough  to  allow  rapid 
execution.  Thus,  parametric  runs  on  normal  and  contingency  re- 
source levels  can  be  executed  to  arrive  at  a highly  desirable 
schedule. 

Because  the  logic  involved  in  the  RES0URCE_ALL0CAT0R  is  some- 
what involved,  an  illustrative,  example  is  presented.  Consider  the 
project  shown  in  Fig.  2.4.32-1.  This  problem  is  taken  from  Davis' 
(Davis,  74)  survey  of  resource  allocation  procedures.  Although 

ft 

it  is  rather  small  to  be  representative  of  practical  projects, 
it  is  of  interest  in  that  the  optimal  solution  is  available  via  the 
algorithm  of  Davis  and  Heidorn  (Davis  and  Heidorn,  1971).  Figure 
2.4.32-2  is  a detailed  trace  of  the  execution  of  the  RES0URCE_ 
ALLOCATOR  logic  for  the  illustrated  resource-constrained  project. 
Sufficient  detail  is  presented  to  allow  the  reader  to  verify  his 
understanding  of  the  algorithm's  logical  flow  as  presented  in  the 
functional  block  diagram.  Next,  Fig.  2.4.32-3  presents  the 
details  of  the  resulting  18-day  schedule.  Contingency  resource 
pool  increments  of  2 and  1 were  available  for  the  first  and  third 
resources,  respectively .Figure  2.4.32-4  contains  the  details  of 
an  optimal  20-day  schedule  generated  by  the  Davis  and  Heidorn 
algorithm  v%rhen  resource  contingency  thresholds  are  not  allowed. 
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Trace  of  the  Execution  of  the  RES0URCE_ALL0CAT0R  Algorithm  on  the  Constrained-Resource 
Problem  Shown  in  Fig.  2.4.32-1,  Using  Contingency  Resource  Thresholds  on  the  F^rst  and 
Third  Resources,  Respectively 


Fig.  2.4.32-2  (aont) 
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Fig.  2.4.32-2  (cont) 
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Vlg.  2.4.32-2  (concl) 
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The  optimal  schedule  requires  two  more  days  than  the  contingency- 
resource  schedule.  Which  schedule  is  suprior  depends  on  the 
availability  of  supplemental  resource  units;  that  is,  on  the 
’’hardness"  of  the  resource  constraints.  It  is  obvious  that  the 
optimal  schedule  is  superior  to  the  25-day  RES0URCE_ALL0CAT0R 
schedule  generated  assuming  no  resource  contingency  levels , as 
shown  in  Fig.  2.4.32-5.  Thus,'  it  is  apparent  that  the  simple 
priority  rule  scheduling  of  the  RESOURCE _ALL0CAT0R,  which  is  in 
force  when  no  resource  thresholds  are  present,  is  greatly  enhanced 
by  the  modifying  heuristic  that  invokes  contingency  resources  when 
an  activity's  late-start  date  is  slipped.  Finally,  it  should  be 
noted  that  by  executing  a series  of  parametric  runs  with  varying 
resource  contingency  thresholds,  a thorough  analysis  of  the 
tradeoff  between  project  duration  and  resource  availability  can 
be  made . 
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2.4.32.9  BKTAILED  DESIGN 

This  module  is  an  implementation  of  a time -progressive  project 
scheduling  heuristic  that  produces  a near -minimum  duration  schedule  that 
satisfies  all  resource  constraints.  On  input,  $JOBLIST  wxll  contain  all 
of  the  information  about  the  set  of  jobs  to  be  scheduled  including: 
resource  requirements,  temporal  relation  constraints  and  critical  path 
data.  $PROFILES  will  contain  a description  of  each  resource  pool,  includ- 
ing time  and  quantity  constraints.  The  output  $SCHEDULE  will  contain  the 
set  of  jobs  along  with  their  start  and  end  times.  $PROFILES  is  updated 
to  reflect  the  resource  allocations  performed  during  the  scheduling 
process . 

The  time liner  steps  through  time,  scheduling  activities  from  a 
prioritized  list  at  each  time  point.  The  activities  are  considered 
eligible  as  soon  as  time  reaches  the  early  start  limit  for  the  activity. 
The  activities  are  prioritized  based  on  late  start  time  limit,  slack 
and  activity  duration.  Activities  from  the  list  are  scheduled  at  the 
current  time  point  as  long  as  resources  are  available.  If  an  activity 
is  not  scheduled  at  its  early  start  time,  its  slippage  may  affectVthd 
early  starts  and  thus  the  slacks  of  its  successors.  If  the  activity  has 
negative  or  zero  slack  and  must  be  slipped,  the  project  length  may  be 
extended  and  the  late  starts  and  slacks  of  other  activities  may  require 
adjustment.  RESOURCE__ALLOCATOR  dynamically  adjusts  early  starts,  late 
starts  and  slacks  to  account  for  slippage  beyond  the  early  start  limits 
of  activities.  However,  it  does  allow  activities  to  be  slipped  beyond 
their  original  late  start  limits. 
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To  determine  whether  sufficient  resources  are  available  to  schedule 
an  activity  at  a given  time,  it  is  necessary  to  know  what  is  needed  and 
what  is  available.  The  amount  of  each  available  resource  is  specified 
as  a pool  level  and  is  allowed  to  vary  as  a function  of  time  unit.  The 
module  also  allows  the  user  to  specify  for  each  resource  required  by  an 
activity  the  time  interval  or  intervals  over  wl  ich  the  resource  is  needed, 
and  an  initial  and  final  quantity  for  each.  The  initial  quantity  is  the 
amount  which  will  be  subtracted  from  the  resource  pool  for  the  duration 
of  the  interval.  The  final  quantity  is  the  amount  vjhich  is  returned  to 
the  pool  at  the  end  of  the  interval.  If  no  interval  is  specified,  it 
is  assumed  that  the  resource  is  required  for  the  duration  of  the  activity. 
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2.4.32.10  INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 


$ALLOCATED_RE  SOURCES 
I_EVENT_JUST_SCHE  DULE  D_ 
FLAG 
$NILL 

LOCAL_INFINITY 

$FINISH_TIMES 

$JOB 

$JOBLIST 

$JOB_INFO 

$TEMP 

$JOBID_TREE 

I_JOB_START 

I_THRESHOLD_FLAG 

I_ALLOCATE_OR_FREE_FLAG 

$ FAILURE_INDICATOR 

KLOCK 

$SCHEDULABLE_JOBS 


lists  the  resources  already  allocated  thus  far 
indicates  whether-or-not  the  job  being 
scheduled  is  an  event 
equivalent  to  $NULL 
equal  to  16000 

contains  the  end  times  of  the  jobs  from  $J0BLIST 
specifies  the  job  in  $JOBLIST  which  is  currently 
being  processed 

the  list  of  jobs  to  be  scheduled 

contains  the  necessary  information  from  $J0B 

to  perform  a critical  path  analysis 

temporary  storage  used  for  many  purposes 

throughout  the  module 

contains  the  label  of  the  current  job 

the  start  time  of  the  job  being  processed 

indicates  whether-or-not  contingency  level 

resources  can  be  allocated 

indicates  what  type  of  update  operation  is  to 
be  performed 

can  be  used  to  input  a time  after  which  resource 
constraints  are  allowed. 

indicates  the  elapsed  time  of  the  schedule  at 
any  point  in  time 

list  of  jobs  which  can  be  scheduled  based  on 
their  predecessor  constraints. 
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$TEMP_JOB 

$FINISHED_JOBS 

$DEIAYED_JOBS 

$IMPORTANT_JOBS 

I_DE  LAYED_JOB__COTJNTER 
I_SCHEDULABLE_J0B_C0I3NTER  - 
$SCHEDULABLES 

$OUTPUT_SCHEDULE 

$SCHEDULE_JOB 

$SCHED_JOB 

II,  Nl,  13,  I , N 

$CURRENT_JOB 

$CONFLICT_TIMES  , 
I_CRITICAL_WARNING_FLAG  ,• 

I_SLACK_UPDATE_FLAG 

$POOL 

$CRITICAL_RES0URGES 
$TEMP_POOL 
$ALLOCATED_RE SOURCES 


temporary  storage  for  the  job  to  be  scheduled, 
list  of  jobs  already  scheduled 
list  of  jobs  delayed  due  to  resource  unavail- 
abilities 

contains  delayed  jobs  which  have  access  to 
critical  resources 
counts  number  of  delayed  jobs 
counts  number  of  jobs  able  to  be  scheduled 
contains  the  name  of  all  jobs  able  to  be 
scheduled 

contains  the  start  time  of  all  jobs  on  $SCHEDULE 
points  at  job  already  on  $SCHEDULE 
points  at  jobs  able  to  be  scheduled 
counters  used  for  various  purposes  throughout 
the  module 

points  at  the  job  able  to  be  scheduled  currently 
being  processed 

contains  the  information  in  $FAILURE_INDICATOR 
indicates  whether-or-not  resources  are  at 
their  critical  point 

indicates  that  job  has  been  delayed  and  slack 
updates  must  be  done 

points  at  subnodes  of  $ALLOCATED_RESOURCES 
lists  resources  which  are  delaying  jobs  being 
scheduled 

- contains  the  resource  in  $CRITICAL_RESOURCES 
currently  being  processed 

contains  resources  which  have  been  allocated 
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$RESOURCE_SHORTAGE 


$CURRENT_JOB_TYPE 
$RESOURCE  S_DE  LAYIN  G_JOB 

JOBj,DURATION 

I__FINISH_TIME 

$MATCH_RESOURCE_TG_JOB 

$CRIT_RES 

$POOL_INDICATOR 

N_SCHEDULABLE_JOBS 

N_SCHEDULED_JOBS 

$TEMP_JOBLIS'r 

I_SPLIT_TIME 

$NEW_JOB 

$RES  OURCE_  SAVE__AREA 

SPLITJTIME 

FIRST_JOB_DURAT  ION 

I_FIRST_JOB_DURATION 

$PREDECESSOR 
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contains  resources  which  are  in  short  supply 
and  therefore  cause  a delay  in  scheduling  a 
job 

contains  the  job  type  of  the  job  being  processed 
contains  the  name  of  the  resource  delaying  the 
scheduling  of  the  current  job 
duration  of  the  job  currently  being  processed 
the  expected  finish  time  of  the  current  job 
contains  list  of  jobs  delayed  due  to  resource 
limitations  with  the  resources  causing  the  delay 
points  at  critical  resources 

points  at  subnodes  of  $RES0URCES_DE1AYING__J0B 

number  of  jobs  able  to  be  scheduled 

number  of  jobs  on  $SCHEDULE 

temporary  storage  for  $JOBLIST 

minimum  value  of  $CONFLICT_TIMES 

a new  job  definition,  made  as  a result  of 

splitting  the  current  job 

condensed  version  of  the  resource  information 
stored  in  $ JOB LIST 

indicates  the  time  at  which  a splittable  job 
is  to  be  split 

duration  of  the  first  part  of  the  splittable 
job 

interger  valued  F1RST_J0B_DURATI0N 
points  to  the  predecessors  of  $NEW_JOB's 
successors 


/ 


$ SUCCESSOR 
INDEX_OF_POOL 

INTERVAL_INDEX 

NEW_INTERVAL_INDEX 

$NEW_POOL 

$JAB 

$RESOURCE_LABEL 

$TYPE 

$POOL_INFO 
$ PARAMETER 

$INFO 

$JOB_RESOURCES 

$JOB_ID 

$CONDENSED 

ICRIT 

$LIST 

$LIST  ELEMENT 


points  to  the  successors  of  $NEW_JOB 
counter  for  number  of  resources  required  by 
the  $NEW_JOB 

points  at  different  resource  types  required  by 
$CURRENT_JOBS 

points  at  different  resource  types  required 
by  ’$NEW_JOB 

points  at  resources  required  by  $NEW_JOB 

points  at  subnodes  of  $SCHEDULE 

keeps  the  labels  of  resources  in  $JOBLIST  so 

that  the  resource  information  can  be  returned 

to  its  original  state  in  $JOBLIST 

points  at  the  subnodes  of  $RESOURCE_SAVE_AREA 

contains  condensed  resource  information 

temporary  storage  for  condensed  resource 

information  before  being  put  into  $POOL_INFO 

points  at  subnodes  of  $POOL 

points  at  subnodes  of  $RESOURCE_SAVE_AREA 

contains  label  of  $JOB_RESOURCES 

intermediate  tree  in  the  return  from  condensed 

resource  information  to  original  state 

index  for  1 to  NUMBER_OF_CRITERIA 

contains  the  list  to  be  ordered  by  different 

criteria 

points  to  the  subnodes  of  $LIST 
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INTERVAL_COUNTER 

MINIMUM 

NSECONDARY 

$PRIME_LIST 

$SECONDARY_LIST 

I_START 

$INCREMENT__CANDIDATES 
IN  IT  I AL__P  A S S_F  LAG 
$PUSHING_JOB 


$SUCCESSOR_SET 

$JOB_TO_BE_PUSHED 

$CURRENT_SUCCESSOR 

$TARGET 

NUMBER_OF_CRITERIA 

MAXMIN_FLAG 

$TRANSFER_INDICES 

I_TRANSFER_INDEX 

$NEW_LIST 
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internal  counter  for  number  of  required  re- 
sources 

equal  to  LOCAL_INFINITY,  or  I_START,  whichever 
is  less 

number  of  jobs  in  $SECONDARY__LIST 
a list  of  jobs  which  have  information 
to  calculate  free  slack  for  $CURRENT_JOB 
list  of  secondary  jobs  needed  to  calculate 
free  slack 

indicates  early  start  of  SPRIME_LIST  successors 

successors  of  $CURRENT_JOB 

determines  definition  of  $PUSHING_JOB 

defined  as  current  job  being  processed  or  a 

successor  of  the  current  job  depending  upon 

value  of  INITIAL_PASS_FLAG 

equivalent  to  $JOBLIST 

a successor  of  $SUCCESSOR_SET 

points  at  subnodes  of  $INCREMENT_CANDIDATES 

equivalent  to  the  description  of  the  job  being 

processed 

specifies  the  number  of  criteria  which  the 
$SCHEDULABLE_JOBS  should  be  ordered  on 
flag  determining  what  criteria  to  order  on 
tracks  the  indices  of  the  variables  in  $LIST 
for  ordering  purposes 
equals  the  value  of  $TRANSFER__INDICES 
contains  the  ordered  $LIST 


$IN_USE 

$POOL_PROFILE 

I_CHECK_TIME 

NUMBER_OF_UPDATES 

$MODE 

$JOB_INTERVAL 

I_START 

I_END 

QUANTITY_DELTA 

$INTERVAL 

NIvAST 

$NEW_INTERVAL 

$INTERVALl 

$INTERVAL2 

$FAILURE_INDICAT0R 
I POINTER 


- the  in  use  portion  of  the  current  resource 
contains  the  resource  profile  for  a given 
resource 

- contains  the  time  in  $FAILURE_INDICATOR 

- equals  2 if  contingency  checks  are  to  be  made, 
equals  1 if  not  the  case 

- reflects  the  user  choice  to  search  contingency 
levels  of  resources  or  not 

- points  at  the  subnodes  of  $POOL 

- the  sum  of  I_JOB_START  and  the  start  of  the 
resource  availability  in  $POOL 

- the  sum  of  I_JOB_START  and  the  end  of  the  resource 
availability  in  $POOL 

- the  initial  quantity  of  the  resource  in  $POOL 
being  processed 

the  inuse  portion  of  $POOL_PROFILE 

- the  number  of  subnqdi-s  of  $INTERVAL 

- equivalent  to  $NULL,  used  to  insert  null 
nodes  onto  $INTERVAL 

calling  argument,  containing  interval  infor- 
mation and  resources  to  be  updated  by  QUANTITY_ 
DELTA 

if  it  is  not  empty,  then  its  associated  quantity 
is  taken  as  the  initial  quantity  of  $INTERVAL1 

- start  of  $INTERVAL1 

- pointer  which  is  decremented  if  $INTERVALl  and 
$INTERVAL2  can  be  combined 
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2,4.32.11  COMMENTED  CODE 


RESOURCE.ALLOCATOK:  RROCEOURE  nfcJOBLiST*  SPROFILES*  SSCHEOULE  ) 

OPTIONS (EXTERNAL) 5 


/tt  */ 

/*  THIS  MOOULF  IS  AN  IMPLEMENTATION  OF  A TIME-PROGRESSIVE  PROJECT  */ 

/«  SCHEDULING  HEURISTIC  THAT  PRODUCES  A NEAR-MINIMUM  DURATION  */ 

/»  schedule  That  satisfies  all  resource  constraints,  a detaileo  */ 

/*  description  of  the  heuristic  can  be  found  in  the  functional  */ 

/♦  specifications  for  this  module.  on  input*  SsJOBLIST  will  con-  •*/ 

/*  TAIN  ALL  OF  the  information  ABOUT  THE  SET  OF  JOBS  TO  BE  SCHED-  */ 

/*  ULED  INCLUOING:  resource  REQUIREMENTS*  TEMPORAL  RELATION  CON- 

/*  STRAINTS*  AND  CRITICAL  PATH  DATA.  SPROFILES  WILL  CONTAIN  A */ 

/<*  DESCRIPTION  OF  EACH  RESOURCE  POOL*  INCLUDING  TIME  AND  QUANTITY  <*/ 

/<»  CONSTRAINTS.  ON  OUTPUT*  SSCHEDULE  WILL  CONTAIN  THE  SET  OF  JOBS  «/ 

/*  ALONG  WITH  THEIR  START  AND  END  TIMES.  ^PROFILES  IS  UPDATED  TO  */ 

/*  REFLECT  THF  RESOURCE  ALLOCATIONS  PERFORMED  UURING  THE  SCHEDUL- 
/*  ING  PROCESS. 

/*  */ 


DECLARE  1>AllOCATE0_R£SOURCES»SC0nFLICT_TIMES*5CRITICAL_J0BS* 

$CRI TICAL_RESOURCE5*SCURRe'NT_JOrf*$OELAYED_JOB_RESOURCES* 
*OELAYEn_JORS*  FFAILUWE^INDICA  TOR  * SF I N I SH„T I MES * SF I N I SHEO.JOBS ♦ I ♦ 
I.SLACK_UPDATE_FLA6*I_CRri  I C AL_ w ARN I NG„FL AG ♦ I_F I NAL^QUANT I T Y ♦ 
llFINlSH^TiME* i_SPLlT_riME* I_S TAR  T * i_ THRESHOLD^FL A6 ♦ 

INITl  AL.QUANTI  TY*  J*!i,JOH*$JOR_lNFO  * KLOCK  * M * M I N I MUM  » N * 
N„SCHEDULABLE_JaBS*N_SCH£DULED_JOdS*  $NEW_ JOB*  SPOOL* 
'fiRESOURC£_SAVE_AHEA*SRESOURCE_SHORTAGE*SSCHEDULABLE_JOBS* 

LOCAl ImFTNITY*  SnILL* 

I.EVEN I_JUST_SCHcDULED_FLAG*  $ i MPOR T ANT_ JOBS  * 
JMATCH_»ESvn)RCE_TO_J08t 

SSUCCESSOR*$TEMP  LOCAL  ? 

/*  FIRST  THE  DATA  STRUCTURE  OF  SJOBLIST  IS  CONDENSED  TO  INCREASE 
/*  THE  EFFICIENCY  OF  NODE  ACCESSES  In  THE  REST  OF  THE  PROGRAM.  */ 

i_event_just«.scheduled_flag  = 0 ; 

SNILL  = 5NUI.L  ; 
local_inftnity  = loouu  ; 

CALL  CONDENSE_RESOURCE_INFORMATION  ( i'JOBLlST  * SRESOURCE^SA VE_aREA ) ; 

$FINISH_T IMEsTfIRST) = LOCAL^lNF INITY  5 
DO  I = NUMHFR (4J0HLIST)  TO  1 HY  -1  ; 

define  :ftJOH  AS  »>J0HLIST{I)  ; 

graft  a>jnB,TFMPURAL_RELATION.PREDECESSOR  AT  SJOB„INFO, 

PREDECESSOR  ; 

GRAFT  SJOB.  TEMPORAI REL  AT  I ON  , SUCCESSOR  AT  '6JOH_  I NFO.  SUCCESSOR  ; 

GRAFT  SJ08. DURATION  AT  ‘S  JOB_  I NFO  . DUR  A TI  ON  ? 

CALL  RE TPIEVE^CRI TICAL_PATH„DATA (4J0B„INFU)  ? 

GRAFT  SJOB. JOB^TYPE  AT  S JOB. I NFO . JOB_T YPE  ? 

CALL  COMmNE_rREFS($JOB.lNFu*SJOB)  ; 

IF  ;FJOfct,jOB.lNltRVAL  (FIRST)  NOT  IDENTICAL  TO  SNULL 
THEN  DO  ) SJOB. FROZEN  s ii  ; 

'«;TEMP.WLABEL  CiJOB)  = t JOB . JOB.INTERVAL .END  \ 

GRAFT  INSERT  STEMP(FlRST)  BEFORE  SFINISH.T IMES (FIRST)  I 
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SJOttlD^TREE  = LABEL (SJOa)  I 
r..JO0_SrAHT  = SJOB.JOB_INTERVAL. START  » 

I ’threshold.flag  = 0 I 
i.,allocate^oh.free«flag  = 1 ; 
i;f  ailure^inoicator  =s  0 ; 

on  FOR  ALL  SOBNOOES  OF  S JOB . RESOURCE  USING  SPOOL  < 
CaLL  iJPOATE_POOL„LFVELS 

( SPOOLS  *JOBIl)_TREE » SPROFILESf  I_JOB_START* 

1_THRESH0LD_FLA6»I_ALL0CAT£.0R_FRE£_FLAG* 

*failure_indicator  ) ; 

EJo; 

r'iiAFT  SUOH  AT  SSCHEOULE  (NEXT ) ? 

FNO  ? 


END 
KLOCK  = 


-1 


BEGIN^MAIN^SCHFOULING^LOOR! 


/* 


/<» 


* RESv’)UHCE«  ALLOCATOR  • . 
UNTIL  all  of  the  jobs 


THIS  IS  TuF  main  loop  OF 
I\(ELT  STEPS  THROUGH  TIME 
BEEN  scHEom.eo. 

IF  SJOBLIST (riRST)  IDENTICAL  TO  SNULL 
» SSCHEOULABLE.JOBS (FIRST) 
THEN  GO  TO  !■  .LOC ATOR_F INAl — PROCEOURES 
IF  AN  EVEN’  HAS  JJST  BEEN  SCHEDULED* 
GIVE  THE  E7£NT*S  SUCCESSORS  A CHANCE 
IF  I_EV£ vT_JUST_SCHEUULEO_FLAG  = 0 
then”  KL’^'CK  = KLOCK  ♦ i » 

FLSf  I EOENT  JUST_SCHF;DULED„FL  AG  = 
IF  ANY  JOt'G  HAVE  JUST  FINISHEU*  THEIR 
IN  SFINISH;D_J0BS. 


IT  progress- 
in  SJOBLIST  HAVE 


IDENTICAL  TO  SNULL 

\ 

UO  NOT  ADVANCE 
AT  the  CURRENT 


THE  KLOCK. 
TIME. 


0 ; 
ID 


numbers  are  RECORDED 


00  I = l 0 NUMBER  ( iFlNISri^TIMES ) ? 

IF  S INISH^TIMES(FIRST)  > KLOCK 

T.'lFN  (50  TO  dUILO_SET«OF_SCHEDULABLE_JOBS  ; 
INSERT  LABEL ( SF I N I SH_T I MES (FIRST ) ) 
before  sf ini shed_jobs ( f I rst ) ; 

PRU'  E SF I NlSH^r IMES ( FIRST ) ♦ 


*/ 

*/ 


'*/ 

*/ 


<*/ 


END  ; 

BUILO  SET^Of'.SCHEDULABLE^JOBSs 

/«  ALL  JOB  ^HOSE  predecessors  ARE  FINISHED  CAN  NOW  BE  ADDED 
/»  TO  iSCFSLHJLABLE.JDBS. 

DO  I = 1 TO  number (SJOBLI ST > » 

geaft  sjobli jT  (F  IRS r ) at  stemp^job  ; 

/•  STFMR.JUB, predecessor  SUBSET  OF  iFI N I SHEO^JOBS 
h KLOCK  >=  ST£MP^J08.hAKLY„START 
THFN  DO  « 

iTEMp^JOB.ENTRY_TlME  = KLOCK  ; 

GRAF  r'"*TEMP_JOB  -AT  ESCHEOUL ABL£_JOBS  ( NEX T ) \ 


END  i 

IF  STFMP^JOB  NOT  IDENTICAL  TO  %NULL 

THFN  GRAFT  :fiTEMP_JO0  AT  S JObL 1 ST ( NEXT ) ; 

END  ? 

ORDER„SCHEnULARLE-.JOBS ! 
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DO  FOR  ALL  SU0NOOES  OF  SSCHEDULABLE^JOBS  USING  $JOB  I 
call  UROATE^SLACK (SJOBf  $J0HL1ST*  SSCriEOULE  ) I 

END? 


/#»******•»*#* 

ORDER  tScHEUULABLE^JOBS  BY 


-LATE  START»-FRE£_SLACK*-T0TAL«SLACK* 

-DURATION  » 


CALL  SCHEOULABLE_JOB.OROER<SSCHEUULA8LE_JObS)  ; 

IF  $delayeo_uobs  not  identical  to  snull 

/*  CREATE  ‘BIMROKT  AM  r^JOBS,  i IMPOR I ANT_ JOBS  ARE  THE  ONLY  ^.opc*/ 

Al  LOWED  ACCESS  TO  CRITICAL  RESOURCES  WHILE  THERE  ARE  $(jELAYEO„JOBS  / 
/»  THEY  CONSIST  OF  tOELA YED_ JOBS  AMD  OTHER  JOBS  WHICH  ARE  RANKED  J 

/<»  HIGHER  IN  The  ordered  SSCHEOUL  A8LE_  JOBS . 

PRUNE  $ IMPORT ANT_J0BS  ; 

I^nELAYED_JOB_COUNTER  = 0 ? 

T^SCHED  JLA8LF.  JGB_COUNTER  = 0 ? _ . 

no  WHIIE  (I  DELAYED  JuB^COUNTER  < NUMBER ( SD£LAYED_JOBS)  ) I 
J^SCHEmj:ArtLE_ll5.COUNTEK  = I.SCHEDULABLE.JOH.COUNTEH* 1 i 

**rAdEL7«SCHErtULABLEljoeS(I_SCHEUULAHLE_JOB  COUNT^  j 
IF  LABEL  ( SSCHE  JULABLE_JOd5  ( I_SCHEL)ULAHLE«.  JOH_COUNTER  ) ) 
FLFHENT  OF  FDELA Y£D_ JOBS 

THEN  Lo£LAYED.JOH„CUUnTER  = 1 .DEL A YED. JOB_COUN TER  ♦!  * 

end; 

end; 

/»  scheoulable  jobs  ANU  DETEW-IINES  «/ 

/.  IhETHER  O«  .^iOr  THEY  CAN  HE  SChEDULEO  WITHOUT  VIOLATINU  ANY  */ 

/*  RESOURCE  CONSTRAINTS. 

ii=i;  , 

N1  = iMUMBER  ( iiSCHEDULABLE^JOBb)  ; 

TEMP_LA0EL1S 

IF  Il>Ni 

ThFN  itO  ro  TEHP^LABELBi 

GRAFT  SSCHEDULABLE^JOBS (FIRST)  AT  iCURRENT^JOB  » 

prune  3>cunflict«tim£S  , ; 

I_CRI TICAL_WARnING_FLAG  = u ; 

THFN'^CALrUPUATF!^SLACK(SCURR£in.J  * 

re  "4;i>Pi  AYFi)  JOBS  MOT  IDENTICAL  TO  tNULL 
‘THEriE'cAHiLUCUHHENT.JUB.  'J'”  f 

then  0^  ^cSSrent.job.hesouhce 

intiTj  r u . USING  SPOOL  ? 

IF  LABEL  (SPOOL)  ELEMENT  OF 

SCRiriCAl RESOURCES  N 

SPOOL(FIRST) .final^ouantity 

<=SPOOL(FIRST) .INITIAL_QUANTITY 

THEN  GO  TO  PUT«J0B_IN«WAIT«STATE  \ 
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ENO  I 

/*  THIS  LOOP  attempts  TO  ALLOCATE  RESOURCES  FOR  THE  JOR  CURRENTLY  */ 
/*  UNDER  CONSIDERATION. 

DO  I = 1 TO  NUMBER (SCURRENT.JOB. RESOURCE)  I 
PRUNE  SFAILURE^INOICATOR  J 

graft  SCURRENT.JOB.RESOURCE (FIRST)  AT  STEMP.POOL  » 

IF  LABEL (JTEMP.POOL)  ELEMENT  OF  SCRITICAL^RESOURCES  6, 
SPR0FILES.#LA6EL (STEMP.POOL) .AVAILABLE.CONTINGENCY (FIRST) 
NOT  IDENTICAL  TO  SNULL 
THEN  I_THRESHOLD_FLAG  = I ; 

ELSE  I_THRESHOLO.FLAG  - 0 ; 

»JOBID_TREE  = LABEL ($CURRENT_J08)  » 

CALL  UPOATE»POOL_LEVeLS(*TEMP_POOL»S JOBIO.TREE* 

iiPROFILESfKLOCK*  I^IHRESHOLO^FLAG*!  t$FAILURE_INDICATOR)  ; 
IF  *FAILURE_INDICATO»  IDENTICAL  TO  SNULL 
THEN  GRAFT  INSERT  STEMP^POOL  BEFORE 

iALLOCATEO.WESOURCES ( 1 ) ; 

ELSE  00» 

GRAFT  INSERT  iTEMP^PUOL  BEFORE 

SRESOURCE.SHORTAGE (FIRST) ; 
LABEL (SCURRENT.J0B_TVPE) = SCURRENT_JOH. JOB_TYPE  I 
IF  LABEL(»CURRENT_JOB_TYPE)  = •SPLITTAHLE* 

THEN  GRAFT  INSERT  liFA  ILURE.INDICATOR  BEFORE 

■dCONFLICT_TIMES(FIRST)  i 
IF  $CURRENT_J0B,LATE_START  <=  KLOCK 

THEN  INSERT  LABEL(SRES0URC£_SH0RTAGE(FIRST) ) BEFORE 
«RESCJURCES_DELAY1NG_J0B  (FIRST)  I 
ELSE  IF  LAdEL($CURRENT_JOH„TYPE)  --=  *SPLITTA8LE» 

THEN  GO  TO  PU T_JOB_IN_WA I T_STATE  ? 

END; 

END  ; 

/»  IF  THE  PRECEDING  ATTEMPTED  RESOUPCE  ALLOCATION  WAS  SUCCESSFUL* 

/*  THE  siOR  CAM  NOW  BE  SCHEDULED. 

IF  liRFSOURCE.SHORTAGE  IDENTICAL  TO  *CONFL  I CT.T  I MES 
THEN  DO  ; 

JOB^OURATION  = *curhent_job.ouration  ; 

IF  JOB^DURATION  = 0 

THEN  I_EVENT_JUST_SCHEDUL£0_FLAG  = 1 ; 

GRAFT  $ALLOCATED„RESOURCES  AT  SCURRENT^ JOB .RESOURCE  ; 
iCURRENT^JOe. JOB^INTERVAL.START  s KLOCK  ; 

I_FINISH«T1ME  = KLOCK  ♦ SCURREnT_JOB,DURATION  ; 
:bCURRENT_J08.  JOB^INTERYAL.END  = I_F  I N 1 3H_T IME  ; 

4 IEMP.)#LABEL  (SCURRENT^JOB)  = I_F  IN  I SH_T  I ME  i 
graft  insert  <TEHP( FIRST)  BEFORE 

SFIMSH_TIMES(F,IRST:  ‘ELEMENT  > I_FINISH_TIM£>  T 

IF  label (SCURRENT^ JOB)  ELEMENT  OF  $DEL AYEO.JOBS 
THEN  DO  ; 

PRUNE  $DELAYE0« JOBS (FIRST:  SELEMENT  = 

LABEL (SCURREnT^JOB) ) ; 

DO  FOR  ALL  SUBNODES  OF 

SMATCH_RESOURCE_TO«JOB.»LABEL (SCURRENT^JOB) . 
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critical^resouhce  using  $crit_res  ; 

PRUNE  .'bCRITICAt^RESOURCES  (FIRST:  -BELEMENT 
IDENTICAL  TO  SCRIT^RES)  I 

END? 

PRUNE  SMATCH_RES0URCE«TU_J08.#LABEL (SCURRENT_UOB) I 
END* 

fiRAFT  $CURRENT_JDB  AT  iSCriEDULE ( NEXT ) ; 

END  * 

ELSE  DO  ; 

DO  FUR  ALL  SUBNOQES  OF  SALLOCATEO„RESOURCES  USING 

SPOOL  ; 

SJOblO^TREE  = .LABEL ( SCURRENf^JOB) { 

CALL  UPDATE^POOL.LE^ELS  l$POOL'»SJOBID_TRE£* 

$profiles9Klock*o*o»sfailure.inoicator)  ; 

EvD  I 

CALL  COmHINE^TREES 

{s>allucateu.>resdurces*4.current_jdb*resource)  ; 
CALL  COMBInE^TREES 

( 1KES0URCE_SH0RTAG£»  SCURRENT„ JOB , RESOURCE  ) ? 

IE  SCURRENT..JOB.LATE_SrART  <=  KLOCK 
THEN  DO  I 

DETERMINE  whether  CONTINGENCY  RESOURCES  WOULD  HELP  <*/ 

00  FOR  ALL  SLIBNODES  OF  iRESOURCES.DELA Y I NG.JOB 

USING  $POOL..INOICATOR  I 
IF  ^profiles.#  ('SPOOL_INDICATOR)  .AVAILABLE. 

CONTINGENCY (FIRST)  NOT  IDENTICAL  TO  SNULL 
THEN  GO  TO  CONS  I DER^RESCHEOUL I NG  ; 

end; 

/*  There  are  no  contingency  resources  to  help  this  job*  so  drop  out 

AND  SPLIT  THE  JOB  OR  PUT  IT  IN  THE  WAIT  STATE  */ 

PRUNE  STEMP  ; 

LABEL (STEMP)  = LABEL (SCURRENT_J08)  ; 
'iTEMP.CRlTICAL^RESOURCE 

= ■6RtS0URC£S_DELAYING„J0a  ; 

GRAFT  INSERT  STEmP  BEFORE 

•fHATCH_RESOURCE_TO_JOb  (FIRST)  i 
CALL  COMBINE^TREES 

( shesources_delaying„job* 

SCRITICAL^RESQURCES)  ? 

IF  SCONFLICT^TIMES  IDENTICAL  TO  SNULL 

Then  go  to  put_joh_in_wait_state  * 

ELSE  GO  TO  attempt„.job_split  ; 

CONS I UER^RESCHEDUL I NG: 

IF  THE  RESOURCES  DELAYING  THIS  JOB  HAVE  ALREADY  BEEN  MADE  CRITICAL*/ 
/*  DON'T  reschedule  BUT  ADD  THE  JOB  TO  TmE  DELAYED  JOBS  AND  ITS  */ 

/*  RESOURCES  TO  SCPiTlCAL  RESOURCES  */ 

IF  'SRESOURC£S_OtLA/ING„UOB  SUBSET  OF 
HCWITICAL^HESOURCES 
THEN  DO  ? 

INSERT  LABEL («CURRENT_J08)  BEFORE 
SUELAYEO^JOBS (FIRST)  ; 
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PRUNE  STEMP  ; 

LABEL  (IfTEMP)  = LABEL  (SCURRENf^JOB)  ; 
'BTEMP.CRITICAL.RESOURCE 

= «RESQURCES.DELAYING_JOB  ; 

GRAFT  INSERT  -BTEMP  BEFORE 

!tMATCH_ReSOURCE_rO.JOB(FIRST)  ; 

CALL  COMBINE.TREES 

( *RESOURCES_U£LAYING„JOe» 
*CRITICAL_RESOURCES)  \ 

end; 

ELSE  do; 

/»  ALL  THE  CONOiriONS  NECESSARY -FOR  RESCHEDULING  HAVE  NOW  BEEN  MET  <*/ 
/*  SO  GO  ro  It 

UEYENT.JUST^SCHE'DULEO.FLaQ  = 0 ; 

INSERT  label < *CURRENT_JOB)  BEFORE 
$OELAYEl)_J08S(FIRST)  ; 

PRUNE  STEMP  ; 

LABEL (STEHR)  = LABEL ( ^CURRENT. JOB ) ; 

STEHP.CRITICAL^RESoURCE 

= JRESOURCES_DELAYING_JOri  ; 

(3WAFT  INSERT  'RTEmP  BEFORE 

$MATCH«RES0URCE_r0_J08 (FIRST)  I 
CALL  COMWINE^TkEES 

( .skesource.s_delaying„job» 
s.cpitical_resources  ) ; 

KLOCK  = »CURWENT_JOB.ENrRY_TlME  » 

DO  13=  number ($SCHEDULABLE_J08S)  TO  1 BY  -i  ; 
IF  SSCHEDiJLABLE^JOBS  { 13)  •ENTRY_TIME  > KLOCK 
TmFN  graft  insert  $SCHEDULA8LE_J0BS(I3) 
before  SJOBLIST (FIRST)  ; 

End; 

DO  J=1  TO  number (SSCHEDULE)  ; 

GRAFT  SSCHEOULE (FIRST)  AT  STEMp_J08  ; 

IF  ST£mP_jOB. frozen  IDENTICAL  TO  $NULL 

THEN  IF  *TEMP„JOB.JOB_INTERVAL. START  >= 

KLOCK 


THEN  DO  ; 

PRUNE  SFINISH_TIMES. j»LA8EL 
(•fiTEMP^JOB) »$FIN13HE0_J0BS, 
»LABEL($IEMP_JOB)  ; 
^JOBID_TREE  = 

LABEL (iTEMP^JOB)  ; 
I-.JOB_STAHT  = 

iTEMP^JOB.JOB^INTERVAL. START  ; 
I_THR£SHOLD_FLAG  = 0| 
I^ALLUCA  rE_OR.FREE_FLAG=0 ; 
iFA  [LURE_INniCATOR  * SNULL; 
DO  FOR  all  subnodes  OF 
STEMP^UOB. RESOURCE  USING  SPOOL  ; 
CALL  UPDATE«P00L«LEVELS 
( SPOOL*  SJOBID^TREE* 
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SPKOKILESf  I_J08_START» 
I„THKESHOLO«FLA69 
I^ALLOCATE_OR.FREE.FLAG* 
$FAILUR£_INDICATOR  ) ; 

END? 

IF  $TEMP_J08.ENTRY_T IME  > KLOCK 
THEN  GRAFT  INSERT 

STEMP^JOB 

BEFORE 

fJOBLIST (FIRST) ; 
ELSE  GRAFT  INSERT 

STEHP^JOB 

BEFORE 

*SCHEDULA8LE_J0BS 
(FIRST) I 


TO  $NULL 

SSCHEOULE(NEXT) ; 


....  END  J 

IF  5»TEMR_J03.  n^T  IDENTICAL 
THEN  GRAFT  STEMP^OOB  AT 
END  i 

GRAFT  INSERT  ‘fiCURRENTi.JOB  BEFORE 

$schequlable_jobs(F1rst) ; 
/<»  IN  order  to  recalculate  The  critical  path  data  for  the  job  net-  <»/ 

WORK*  ALL  OF  the  JOBS  FOUND  IN  ^SCHEDULE  AND  iSCHEDlJLABLE^JOBS  <*/ 
ARE  combined  WITH  THOSE  IN  SJOBLIST,  •»/ 

DO  FOR  ALL  SUBNODES  OF  "^SCHEDULE  USING  $JOH  ; 

SJOB. start, EARLT  = s JOB\ joh^interval.start; 

END  5 

N_SCHEDULAdL£_JOBS=NUMHER (JSCHEOULABLE.JOBS)  ? 
N^SCHEOULEO^JOBS  = NUMBER  ( .?iSCHEDUL£  ) ; 

CALL  COMBINE„TREES 

('BSCHEDULABLE^JOBSfiJOBLlST)  T 
DO  FOR  ALL  SUBNOOES  OF 
SJOBLIST  USING  SJOB  I 
PRUNE  S JOB.EARLY^S TART* 
SJOB.EARLY^FINISH* 

•S  JOH,LATE_START* 
SJOB.LATE.FINISH  I 


■M’ •»■!»  a- / 


end; 


ORDER  SSCHEDULE  BY  -JOB^INTERYAL.START  I 


call  OROER„Br_JOH_S  TART  ( SSCflEOULE)  » 

CALL  COMHINE^TREES  (.SSCHEDULE*  SJOBLIST)  ; 

DO  FOR  ALL  SUBnODES  OF  SJOBLIST  USING  $JOB  ; 
GRAFT  S JOB. predecessor  'At 

SJOB‘.TeMPORAL_WELATION,PREUECESSOR  ; 
GRAFT  SJOB. SUCCESSOR  AT 

SJOH.TtMRORAL„KEL AT  I ON, SUCCESSOR  ; 

END  5 

GRAFT  SJOBLIST  AT  STEMP_J0BL1ST  ; 

CALL  CRI  f lCAL-,PATH_CALCULATdR 
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{ STEMP_J0BLIST»  SJOBLiSr  ) I 
PRUNE  STEMP^JOBLIST  5 

DO  FOR  ALL  SUBNODES  OF  SJOBLISf  USING  $JOB  \ 

graft  SJOB.TEMPOHAI RELATION .PREDECESSOR 

AT  SJOri. PREDECESSOR  J 
GRAFT  $ JOB. TEMPORAL^REL AT  I ON. SUCCESSOR 

at  3>job. successor  i 

call  RETRIEVE_CRITICAL.PA7H.DATA (SJOB)  ; 

END  i 

DO  K=1  TO  N.SCHEDULED.JOBS  ? 

graft  .tJOBLIST  (FIRST)  AT  SSCHEDULE  ( NEXT  ) 7 

END  ; 

DO  K=1  TO  N.SCHEDULABL£«JOHS  7 

GRAFT  SJOHLIST (FIRST)  AT  fSCHEOULABLE.JOBS 

(NEXT)  7 


End  7 

GO  TO  ORDER.SCHEDULABLE^JOBS  7 
END  7 
END  ; 


attempt.job.split; 


/tt  SINCE  ALL  OTHER 
/«  THE  JOB  IS  DONE 


ELSE  DO  7 

CALL  COMB JNE.TREES 

(SALLOCATED.RESOURCeSfSCURRENT.JOB.RESOURCE)  7 

call  COHUINE.TREES 

($RE SOURCE. Short AGE »*CURRENT.JU8. RESOURCE) 
IF  iCONPLICTlTIHES  NOT  IDENTICAL  TO  J.NULL 
scheduling  attempts  have  FAILED*  SPLITTING  OF 
AS  A LAST  RESORT. 

THEN  DO  7 

CALL  FIND.MlN 

(SiCONFLlCT  TIM£S*SDUMMY*  VALUE.HINIMUM)  7 


7 


1. SPLIT. TIME  = VALUE.MINIMUM  7 
CALL  JOB.SPLITTER 

( SCURRENT.JOB* I.SPL IT.TIm£*$NEW.J08)  7 
IF  ^NEW„J0^3  NOT  IDENTICAL  TO  TNULL 
THEn”'dO  7 


insert  «R£S0URCE_SAVE.AR£A, 
#LABEL(SJOB)  BEFORE 
ShESOUPCE.SAVE.AREA (FIRST) 7 


ORIGINAL  PAGE  IS 
OP  POOR  QUAiny 


LABEL ( ifiRESOURCE.SAVE.AREA 

(FIRST) )=  LABEL (SNEW^JOB)  7 
GRAFT  INSERT  '6CURREN  T.J()B 
BEFORE  SSCHEDULABLE.JORS U)  7 
GRAFT  'B NEW. JOB  AT 

SJOBLIST (NEXT ) 7 

GO  TO  OkUER_SCHEUULABL£.JOBS; 


END  7 


END  ! 


END  7 

ENO  7 

PUT  JOB.IN.WA IT. state; 

IF  5CURRENT.J08  NOT  IDENTICAL  TO  4NULL 
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/.  SINCE  THIs'^JorHAS  BEEN  DELAYED,  US  CrtITICAL  PATH  DATA  (AND 
/»  POSSIBLE  that  of  its  SUCCESSORS)  I'^UST  BE  HEAOJUSTtU, 

'♦iCUKHENT.JOH.EARLY^srAHT  •■=  KLOCK^l  } ltimtcih+II 

tCURRE;MT.J0ri.EARLY_FIi^I5H  = SCU«RENT_J0B.EARLV_FlNlSH  1 1 

IF  *CURRiNT_JOH,FHE£_SLACK  = 0 

THEN  1)0  ; I_SLACK_UPDATE_FlAO  =*  1 ? 

call  INCREHe(NT_SiJCCESSOR„TIM£S 

( •6CURREi'JT_JOB»  tJOHLiST  ) » 


/* 

/» 

/* 

/* 


END  ♦ 

IF  SiCURREMT_JQH  • TO  r AL_SLACK  <=  O' 

THEN  00  ? • 

fCURK£NT_JOri*LATE»START  - 

SCURRENT_JOH,LATE„START  ♦ 1 I 

FCURRENT_J08«LATE_FIN1SH  = 

‘fcCURRENT^JOH.LA  TE^F  INISH  <-  1 « 

00  FOR  Al  L SUHNOUES  OF  SSChEOUL AdLE^JOBS  USING 

iJOB  » 

tJOB.LATE^START  = $jOb»LAT£_SrA«T  ♦ 1 * 

$JOB.LATE_FINlSri  =*  $UUB  . LA  TE„F  I N I SH  ♦ 1 ; ' 


00  FOR  all  SUBNOOES  OF  SJOBLIST  USING  $»JO0  I 
‘fiJOH.LArE^.START  = S JOB  .L  A T E_S  T AR  T ♦ 1 ; 

'f  J0H,LATE_FJNISH  = i JOB  .LATE^F  I N I SH  ♦ 1 I 

£ (N  0 ♦ 

DO  FUR  ALL  SUBNOOES  OF  «SCHtOULE  USING  SJOB  I 
SuOH.LATE^START  - SJOB.L ATE^START  ♦ 1 i 
:«J08.LATE_FInISH  = * JOP  . L ATE«F  IN  I SH  ♦ 1 I 


NOW  THE 

resource 
WILL  BE 
THIS  JOB 


E N 0 5 

ENU  i 

resources  previously  ALLOCAreo  CAN  be  freed,  the 
u>nOLS  ARE  then  reordered  SO  THAT  THE  CRITICAL  POOLS 
CONSIOEREU  FIRST  ON  THE  NEXT  SCHEDULING  ATTEMPT  FOR 

1)0  FOR  ALL  SUBNOOES  OF  1)  ALLOC  ATEU_R£S0UHCES  US  I 


*/ 

«/ 

NG 

sPuoL  ; 


a».)OHlO_TREE  = LABEL  ( UCURREN  T^JOB ) ; 

call  UPDATE^POOL^LEVELS (SPOOL »$J0BI0_TREE» 

tPROF  i l.ES  » KLOCi^  » 0 ? 0 » SF  A I LURE_  1 NO  I C ATOR  ) 


EmO  ? 

CALL  COMB INE^TREES 
( '^allocated. 


RESOURCES*  SCURRENT_ JOB. RESOURCE) 


Call  CoMBlNE_TRf:E.S 

(SRES0URCE_SHUHTAGE*'SCURRENT_J0B.RES0URCE> 
GWAFr  ,fcCURRENT„JOB  AT  $SCHE!)ULAHLE„  JOBS  ( NEXT ) I 


END  ; 

GO  TO  rFMP._LAHELH 

TEMP.LABELP5  , . . 

GO  TO  BEGIN_MA1N_SCHEDULING_l0OP  * 

ALLOCATOR_FINAL_PROCEOURES: 


2.4.32-42 
Rev  G 


f 


/# 

/* 

/* 


cTWAM  Y.  THE  OAfA  STRUCTURE  OE  THE  JO0  NODES  CAN  BE  EXPANDED 
BACK  TO  THFIR  OKIOINAL  FORM  BEFORE  RETURNING  ^SCHEDULE  TO  T E 

DO  FOR 'all  subnodes  OF  ^SCHEDULE  USING  SJOB  i 

CALL  UPDATE«SLACK ( SJ08 * $SCHEDULE»  iJOBLIST  ^ * ooFnFrFSSOH  : 
roAFT  t;  inB  PREDECESSOR  AT  SJ06  • TEi'iPORAl — RELATION.PREDECESSOR  i 
^Jop'.SUCCEfsOR  AT  SUOB.TEMPORAL.RELATION.SUCCESSOR  ; 

HIJOB.EARLY.STAWT  at  ‘i)dOB  .start  .early  I 
SJnB.LATE^START  AT  SIJOB. START. LATF.  * 

SJOB. EARLY  FINISH  AT  :b  JOB  . F I NI  3H  . E ARL  Y ? 

SJOB:LAr£_FINlSH  AT  ’*‘^08  .F  INISH.LATJ  | 

.■fiJOB.  TOTAI SLACK  AT  $JOB  .SLACK.  TOTAL  ? 

5J0B.FREE_sLaCK  AT  5J‘J'^*SLACK.FRbt  ; 
insert  f JOB.JOB.InTERVAL  before  4J0B (FIRST)  ? 
SJOB.ENTRY^T IME  i 


*/ 

<*/ 

*/ 


GRAFT 

GRAFT 

GRAFT 

GRAFT 

GRAFT 

GRAFT 

GRAFT 

GRAFT 

PRUNE 


END  ; 

ORDER  'fcSCHEOULt 

CALL  ALLOC A I OR_F I NAL^OROER ( ^SCHEDULE ) 


BY  -JOB^IN (ERYAL. START  »-DUKATI0N 


JOB 

/* 

/* 

/« 


/* 

/* 

/* 


splitter:  procedure  (FJOB.  SRLIT_TIME*  iNER_UOB)  ? 

THIS  PROCEDURE  BREAKS  SUOrt  INTO  TWO 

TWO  resultant  jobs  are  returned  in  SJOB  and  iNtW_JOB. 

DECLARE  SPREDECESSOKf  ^SUCCESSOR  LOCAL  i 
PRUNE  snew^jor  ; , . 

FIRST_JOd„DURATI‘)N  = SPLU-TIME  - KLOCK  ; 

I FIRST  JOB  DURATION  = FIRST,.J0B^DURATI0N  T 
IF  I.FIR^T^JOB^DURATION  - U then  RETURN  ? 
iNEW_JOB  = 'CUOB  ♦ • 

TEMP  = LAREL(^JOB)  ? 

TEMP  = TEmP  «•  O.i  S 
LABEL  ( *nEW^..)'.iB  ) = TEMP  » 

FIX  THE  temporal  QUANTITIFIS  OF  *UOd  AND  iNEW^JQB 

imr  duration  “ F I RS  T^  JOH^DUR  A T I ON  I 

sjob!farly_finish  = SJOB.EARLY.START  ♦ * 

'fiJOB.LATE^FINlSH  = S JOB . LATE^ST ART  ♦ $ JOB . OUR AT  I ON  T 
PRUNE  S JOB . SUCCESSOR  T _ . , > . 

i JOB.  SUCCESSOR  (FIRST  ) = LABEL  ( SNEvC-JOB ) » 

**NfLjOB!nu!^A^Io"^  DURATION  - f I NS  r.UOD.UUHAT  ION  S 


*/ 

*/ 

*/ 

*/ 


<*/ 


CS5 
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PRUNE  SNEW_JOB.PHEOECESSOR  i 
SNEiCJOB.PREOEGESSOR (FIRST)  = LABEL(SJ08>  ; 

DO  FOR  ALL  SU8NOOES  OF  $NEW_JOH » SUCCESSOR  USING  fSUCCESSOR  ? 

DEFINE  *>^HFOEC£SSUR  AS  $J08L I ST ,#( SSUCCESSOR ) .PREDECESSOR  » 
PRUNE  TRREDECESSOR (FIRST:  SELEmENT  = LABEL (SJOR)  ) t 
INSERT  LADFL  ( SNEW^JOH)  HEFORE  'RRREOECE  SSOR  ( F I RST  ) ; 

end; 

4NEW_JOB.FARLY_S TART  = SNE W„JOB . £ ARLY^S TART  ♦ F I RS T_ JOB_DURA T I ON  I 

snew_jor.late_star r = $new_job.late_stakt  + first_job_l)Uration; 

SNEW_U0B.FARLY_FINISH  = SNEW_JOR.EARLY_STaR  T’  + SN£t')_JOB«OURAT  ion; 
SNEW^JOB.l  AT£_FINISH  = $NE  • L Ai  E^START  5bNEW_JOB  . DURATION  ; 

snew_job.fntry_time  = klock  ; 

■»/ 

FIX  UP  thf  resource  requirements  in  the  split  jobs  ■»/ 


do  INDE'X_OF_POOL  = 1 To  NUMBEHR ‘fiUOB. RESOURCE)  ; 
intervaL-TNuEx  = i; 

NEW_INTER\/AL_INDtX  = i; 

DEFINE  'fiPOOt.  AS  frJOR. RESOURCE ( INOEX_UF_POOL)  ; 

DEFINE  tiNFW_POOL  AS  :6NEW„JOB  « RESOURCE  ( I NDE X_OF_POnL ) I 

DO  INTFRVaI COUNIEK  = 1 TO  NUMBER ( SPOOL ) ; 

IF  KLOC*<'  + SPOOL  ( INT£R\/A1 I NDE X ) . END  <=  SPLI  T_T1ME 

THEN  do; 

PRUNE  SimFi^_POOL  (NEW_.llV  rERVAL«INi.)EX  ) ; 

INTEHVAI INOEX  = INlERVAL^lNUhX  + 1 i 

end; 

ELSE  IF  KLOCK  > SPOOL ( 1 N TERVAL_ INDEX ). ST AR T 

>=  SPLIT^TIME 


thfn  Do; 

SMtW_iH)OL (NE^_1NTERVAL_1NDEX)  .START  = 

:t.iMEwZPOOL  (NE*W«IN  r ER VAI INDEX  ) .START 

- FIRST_JOH«DUHATION  ; 
Si')EW_POnL  (NEW_1N  rERVAL_lNDEX)  .END  * 

SnEwIpoOL ( NEW_INlEKVAi INDEX) .END 

- first.job.duration  ; 

PRUNE  SPOOL ( INTERVAL^INUEX)  ; 

NE^-iL,lNTEH^A| index  = NEW_1NTERVAI INOEX  ♦ i; 

ENo; 

ELSE  do; 

SPOOL ( 1NTERYAL_INDEX) .END  = 

first_job_duration  ; 

SPoOLdMTEKVAL^ltVOtX)  .FINAL_QUANTirY  = 

SPOOL ( InTERVAL_1NDEX) . INI TiAL^QUANT I TV  ; 

.fiNEw^PuOL  ( NER„INTER\/aI INDEX), START  = U ; 

:bivEW_PODL  (NEw_I,MTERVAL_InUEX  ) .EM.)  = - 

SNEN^POOL  (Nr:iV_iNTFRVAl INDEX)  .END 

- FIRS r_JOH_DURATIOM  » 

IN  I'ERVAL^INDEX  = IN  TER  VAL_  INDEX  ♦ 1 ; 

NE»^„INTeRVAL_lNOEX  = N£iV_iNTERVAL_INDEX  + i: 

End; 

end; 
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ENDJ 

ENDJ  JOB.SPLITTEH  «"/ 

update.slack;  procedube 


SPRIME.LIST*  *SEC0NDARY_LIST  ) ? 

THE  TOTAL  AND  FREE  SLACK  FOR  THE 


/*  THIS  PROCEDURE  RECALCULATES 
/*  vJOa  PASSED  TO  IT  IN  SJOB. 

DECLARE  I*  minimum*  NSCHEDULE  LOCAL  I 

SJOB.TOTAI SLACK  = * JOB.LATE^ST ART  - S JOB • EARLY^S TART  I 

MINIMUM  = local_infinity  ; 

NSECONDARY  = number  (SSEC0N).)ARY_L1ST)  5 

CALL  C0MBINF_TREES ( $SECONOARY_LlST * SPRIME_LIST  ) i 

DO  FOR  ALL  SUBNODES  OF  *JOB . SUCCESSOR  USING  SSUCCESSOR  5 

X^START  = SRRIME_LIST,# (SSUCCESSOR) ,EARLY_START  ; 

7f  I START  < minimum  THEN  MINIMUM  = I„START  ; 

END  T 

IF  MINIMUM  L()CAL_1NFINI  l Y 

THEN  flR».)OR*FKEE_SLACK  = MINIMUM  " iJOB.EARLY^F  INISH  f 
DO  I = NSECONDARY  TO  1 BY  -1  ♦ 

GRAFT  INSERT  SPRIME.L 1ST ( I)  8EFURE  SSECOND AR Y_L I S T ( P I RST ) . 

end; 

end;  /*  UPOATE_SLACK 

INCREMENT  SUCCFSSOR^TIMESJ  PROCEDURE  (!PJOB»  SSUCCESSOR.SET ) T 

DECLARE  3»INCREMENT_CANDIDATES*  4>PUSH I NG^JOB ♦ S JOB_TO_BE_PUSHEO  * 
INI  nAL_PASS„FLAG  LOCAL  ? 

tINCREMENT_CANDIDATES(FIRSr)  ~ S JOB . SUCCESSOR  » 

LABEL  ( SINCRFMENT^CANDIDaTES  (FIRS  r ) ) ==  LABEL((>JOB)  » 

INITIAI PASS.rLAG  = 1 * ^ ^ , . 

DO  WHILE  { FT NCREMENT^C AND  I OATES ( F IRST ) NOT  IDENTICAL  TO  SNULL)  » 

IF  INITIAI PASS^FLAG  = 1 

THEN  do;  OEFINL  SP0SHING_J0B  as  SviOB  s 
iNi r 1ml_pass_flag  = 0 ; 


ENu: 

ELSE  OEFINE  liPUSHlNG_ job  AS 

SSUCCESSOR.SET.WLABLL (FINCREMENT_CANDIDATES (FIRST) ) ; 

DO  FOR  AIL  SUBNOOES  OF  F I NCREMENT.C AND  1 0 ATES ( F I RS T) 

USING  iCURRENT^SUCCESSOR  ♦ 


DFFINP  $JOB_ro_BE, PUSHED  AS 

FSUCCESSOi^.SET  . A ( SCURNENT_SUCC£SS0R)  ; 

IF  FPIISHINQ  JOB.EARLi'^FINISH  > SJOd_T  O.BE.PUSHED  * EARL  Y_ST  ART 


thfn  do; 

FJUH^TO^BF^PUSHFU.EARLY^START  = 

l»PUSHiN(?_JOB,£ARLY_FlNISH  i 
FJOB  TO  BE„P‘JSHEL).eARLV_FINI  BH  = 

" " SJOB^ro^BE^PUSHEO.EARLY^START 

+ FJOB_TO_BE_PUSH£D.DURATION  ; 

SINCREMEN  r_CANDl’DA  TES  (NEXT  ) = 

;BJOd_TO_BE_PUSHEU.  SUCCESSOR  » 

label ( «INCREMENT_CANU IDATES (LAST) ) = 

I ALjcri  mu  Tn  ue  PimUPOl  1 


End; 


end; 

PRUNE  S IMCWEMENT^CANOIDATES (FIRST ) ; 
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/#  INCREMEMT_SUCCESSOS^_TIMES 


ENDI 
ENDI 

RETRIEVE.CRITICAL«RATHJ)ATA:  PROCEDURE  (SrARGET)  ? 

/»  THIS  CODE  TRANSFERS  fHE  CRITICAL  PATH  DATA  OF  SJOb  INTO  STARGET,  */ 
GRAFT  «JOH.«;TaRT.EARLY  AT  tTARGET.tARLY_START  5 
GRAFT  'tjOH.FiNiSH.EAKLY  AT  S T AHGET . EARLY^F I NI SH  5 
GRAFT  $JOb. START. LATE  AT  ? T ARGET . L ATE.S T AR I i 
GRAFT  SJ08. FINISH. LATE  AT  $TARGE f .LATE^F I NI SH  ; 

GRAFT  *JOH. SLACK. TOTAL  AT  &T ARGET . TOTAL^SLACK  » 

GRAFT  .1i  JOB.  SLACK.  FREE  AT  S TARGET  . FREE^SLACK  5 
END!  RETpIEVE^CRI  TICAL_PATH_DATA 

SCH£DUL4RLE_J0B.0RDEW!  PROCEDURE  ( iSCHEDULAHLE^JOBS ) % 


/# 

/*  ORDER  *SCHEDULABLE„J0BS  BY  LOWEST  VALUE  OF  LATE_START»  */ 

FREE.SLACKs  TOTAL„SLACK  AND  DURATION  */ 

/* 


IF  iSCHEOULAHLE«JOHS(FIfiST)  IDENTICAL  TO  SNULL  THEN  RETURN  I 
DO  FOR  ALL  SUDNOUES  OF  SSCHM'JUL ABLE.JOBS  USING  SSJ08  ; 

GRAFT  INSERT  i>S  JOB  . LATE„ST  AR  C BEFORE  SSJOB  (FIRST)  % 

GRAFT  INSERT  SS JOB . F REE^SLACK  BEFORE  SSJOB(FIRST)  I 

GRAFT  INSERT  SS  JOB  . TuT  AL„SL  ACK  BEFORE  4S  JOB  (FIRST)  (i 

GRAFT  ImSFRT  <SS  JOB . DU«  A T I ON  BEFORE  $SJOB(FIRST)  ; 

END! 

NUMBER_oF_CRlTERiA  = 4 ; 

HAXMIN.FLAG  = -1  ; 

CALL  MUL ri_CHI TERI A_OROER 

( SSCHEUULAdLE_JOHS*NUNBER_OF_CRI TERIA»MAXMIN_FLAG  ) ; 

END*  /4  SCHFDJL  AHLF._JOB_ORUER  ■»/ 

0RDER_BY_J0B_START : PROCEDURE  (^SCHEDULE)  ♦ 

/»  ORDERS  ibSCHEOULE  BY  - JOH.I  NTER VAL . STAR  T »/ 

DECLARE  SJAH  LOCAL  ; 

DO  FOR  ALL  SUHNODE.3  OF  ^SCHEDULE  USING  *JAB  5 

INSERT  SJAB.JOB^InTEPVAL. start  BEFORE  SJAB(FIRST)  ; 

end; 

CALL  MJLT  I_CRUERlA_ORueR  CbSCHEDULE*  !♦  -i)  \ 

DO  FOR  ALL  SUHioOOES  OF  fSCHEUULE  USING  SJAH  ; 

PRUNE  tJAB( FIRST)  ; 
end; 

end;  OWD!-:P_Pr„JOB„ST  ART  ■'>/ 

ALLOCATOH_FINAL_OROE'R  : PROCEDURE  (^SCHEDULE)  ? 

/*  ORDERS  .'fiSCMEDULE  BY  - JOB_  I N TER  V AL  . S T AR  T » -DURATION  */ 

DECLARE  *JAR  LOCAL  5 

DO  FOR  ALL  SUBNODES  OF  ‘fiSCMEijUl.E  USING  SJAB  5 

INSERT  'bjAB. JOB^InTERVAL.START  BEFORE  SJAB (FIRST)  ? 

GRAFT  Insert  SJaH. duration  before  SJAB (FIRST)  ; 

END? 

CALL  MUL  ri_rRITF.RlA„ORDER  (^SCHEDULES  2^  -1  ) ? 

DO  FOR  ALL  SUBNODFS  OF  SSCHEOULE  USING  SJAB  I 
PRUNE  S)JAB  (2)  ; 

END  ; 

end;  /4 

END? 
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ALLOrATUR^FlNAI ORDER 

/*  RESOURCE^ALLOCATUR  4/ 


2.4.33  RESOURCE  LEVELER 


2.4.33  RESOURCE  LEVELER 


2.4.33 


% 


RESOURCEJ.EVELER 

2.4.33.1  Purpose  and  Scope 

In  many  project  scheduling  situations,  the  pattern  of  resource 
utilization  is  often  more  important  than  the  quantity  of  resources 
used.  For  example,  a resource  feasible  schedule  that  results  in 
rapidly  changing  resource  requirements  is  clearly  undesirable  from 
the  project  control  standpoint.  In  these  situations  it  is  useful 
to  perform  resource  leveling  in  order  to  reduce  resource  profile 
fluctuations. 

Conceptually,  a resource  utilization  profile  is  level  when  the 
actual  quantity  of  resource  used  in  each  time  period  is  constant. 
Unfortunately,  ‘it  is  not  generally  possible  to  maintain  perfectly 
level  profiles  and  simultaneously  satisfy  all  of  the  scheduling 
constraints.  As  a consequence,  some  fluctuations  will  inevitably 
remain  in  the  resource  profiles.  The  purpose  of  this  module  is 
then  to  minimize  these  remaining  resource  variations.  This  is 
accomplished  by  heuristically  minimizing  the  sum  of  the  squares 
d;  the  resources  over  time,  subject  to  the  network,  resource 
availability,  and  activity  completion  constraints. 

This  module  is  applicable  to  the  general  class  of  project 
scheduling  problems  that  includes  multiple  resources  with  time 

varying  pool  levels. 

2.4.33.2  Modules  Called 
None. 
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2.4.33.3  Module  Input 


1)  Nominal  Schedule  ($SCHEDULE) 
^SCHEDULE 


2)  Nominal  Resource  Profile  ($PR0FILES) 


SPROFILES 
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2.4.33.4  Module  Output 


1)  Revised  "Level"  Schedule  ($SCHEDULE) 


(Same  structure  as  input.) 

2)  Revised  "Level"  Resource  {$PR0FILE) 
(Same  structure  as  input.) 

2.4.33.5  Functional  Description 


The  resource  leveling  procedure  is  based  on  the  minimxzatxon 
of  the  sum  of  the  squares  of  the  resources  over  time.  The  formu- 
lation of  resource  leveling  as  a least  squares  minimization  prob- 
lem is  motivated  by  the  fact  that  a level  profile  minimxzes  the 
sum  of  the  squares  of  the  resources  subject  to  the  constaint  that 
the  area  under  the  profile  is  constant.  A simple  example  best 
illustrates  this  principle.  Consider  a single  resource  defxned 
over  T equally  spaced  time  periods  of  unit  duration,  as  illus- 
trated in  Fig.  2.4.33-1.  Furthermore,  let  r^  denote  the  quantity 
of  resource  used  in  period  i.  It  is  then  possible  to  show  that 
the  level  profile 


r^  — R/T,  i — 1,2,...,  I, 

V 2 

minimxzes  : Lu  , 


subject  to  the 


constraint : 


Er,  = R 


U3 
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CD 
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pi 
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R/T 


I 


Time  Units 


Fig.  2.4.33-2 

Profile  for  Single  Resovirae 
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Unfortunately,  this  simple  leveling  concept  neglects  the  network, 
the  resource,  and  the  integer  start  time  constraints.  Wlien  these 
constraints  are  included  the  resource  leveling  problem  is  stated 
as  follows . 

Determine  the  activity  start  times  s^,  i = 1,  2,  ...  , I,  that 
minimize 

= E E ( E 

k=l  t=l  ' if:d?|. 

subject  to  network  constraints 
[2]  > f^  for  all  2,  . . . . , I 

Bcsource  constraints 

E \i  “ ®i)  tt(s,f) 

is^. 

1 

Activity  completion  constraints 

[4]  E E E V - =i) " <" 

k . t i 

Integer  start  times 
for  all  i. 

1 

In  this  formulation,  K is  the  number  of  resource  types,  T is  the 
number  of  scheduling  time  intervals ,J? ^ is  the  set  of  indices  for 
the  resources  being  used  during  time  interval  t,  It  — s^)  is 
the  quantity  of  resource  type  k used  by  activity  i in  period  t, 
and  R,  (t)  is  the  time  varying  resource  level  for  resource  k. 


[1]  f(si,S2, ■ ...  , 
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This  formulation,  which  represents  a nonlinear  integer  program, 
cannot  be  cost-effectively  solved  with  an  existing  algorithm.  As 
a result,  a heuristic  algorithm  is  used  to  obtain  a solution. 

This  heuristic  assumes  that  a nominal  schedule  is  input  that  satis- 
fied all  of  these  constraints.  A new  start  time  is  then  deter- 
mined for  activity  i by  minimizing  the  partial  sum 


K 

f . 

1 \2 

■ L 

^ { 

^ r,,  (t  - Si)  . r,,  (t  - sj 

k=l 

t=s* 

1 

In  the  above  experession,  s*  is  obtained  from  input  and  is  the 

a 

original  scheduled  start  time  of  activity  i,  and  f^  is  the  latp 
finish  of  activity  i.  The  restriction  of  the  minimization  of 
F^s.j  to  the  interval  defined  by  s*  and  f^  insures  that  the  net- 
work constraints  remain  satisfied.  The  resource  limits  are 
satisfied  by  setting  the  function  F(*)  to  an  arbitrarily-' large 
value  for  all  start  times  that  result  in  a resource  violation  in 
some  time" period.  This  ensures  that  start  times  that  are  re 
source  infeasible  are  not  selected  in  the  minimization  process. 
If  more  than  one  start  time  produces  the  same  minimum  value  of  F 

given  by 
^ _ minimum 


than  the  latest  start  time  is  selected.  This  gives  the  algorxthm 
more  freedom. to  delay  earlier  scheduled  activities. 


The  sequence  in  which  the  new  start  times  are  calculated  is 
determined  by  ordering  the  set  of  activities  according  to:  (1) 

latest  scheduled  finish  and  (2)  largest  residual  total  slack. 

Thus,  the  first  activity  to  be  rescheduled  is  the  last  activity 
completed  in  the  nominal  schedule.  Rescheduling  proceeds  ac- 
cordingly until  a nev7  start  time  for  all  activities  are  calcu- 
lated. The  entire  leveling  process  can  then  be  repeated  until 
the  resulting  profile  remains  unchanged. 

Clearly,  this  sequential  one-dimensional  minimization  heuristic 
does  not  necessarily  produce  the  actual  optimum  start  times.  How- 
ever, our  limited  experience  indicates  that  this  simple  procedure 
can  significantly  smooth  resource  profiles.  This  is  particularly 
true  when  this  algorithm  is  applied  to  schedules  generated  by  re- 
source allocation  heuristics  that  schedule  as  soon  as  the  required 
resources  are  available.  Rescheduling  in  a reverse  least  square 
fashion  naturally  delays  activities  providing  more  free  float  to 
earlier  activities  that  must  be  rescheduled  to  level  resources. 

This  natural  delaying  action  tends  to  shift  resource  "peaks”  that 
occur  early  in  the  scheduling  horizon  in  order  to  fill  later  re- 
source "valleys."  This  also  offsets  the  "tailoff"  problem  asso- 
ciated with  project  completion. 

As  indicated  in  the  formulation,  the  resource  requirements 
can  vary  over  the  duration  of  the  activity  and,  similarly,  the 
resource  pool  levels  can  vary  over  the  duration  of  the  project. 

This  is  illustrated  in  Fig.  2.4.33-2  for  an  arbitrary  resource 
type. 
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Hg,  2.4.33-2  Time-Varying  Resource  Variables 
This  module  can  also  be  easily  modified  to  solve  the  resource 
profile  shaping  problem.  This  can  be  accomplished  by  minimizing 
the  square  of  the  differences  between  actual  and  desired  resource 
profiles . 
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2.4.33,6  Functional  Block  Dxagram 


ENTER 


Build  a list  L consisting 
of,  all  activities.  Order 
L as  follows: 

1.  Latest  scheduled 
finish. 

j a.  Minimum  residual 
slack. 


Initialize  current 
activity  to  first 
element  in  L. 


Set  current  activity 
to  the  next  element 
in  L. 


re  sidual  slack^^ 
of  current  activity 
positive 


current 
activity  the 
last  element 
in  L ^ 


Determine  all  values  of  that 
minimize:  F(s^)  , 
subject  to: 

- =i>  - V=> 

i - 1-  X • 


Set  start  time  of  current 
activity  to  the  l.itest 
start  time  that  mi.nimizes 
FCSf)  . _____ 
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2.4.33.7  Typical  Application 


Resource  leveling  techniques  are  used  to  distribute  resources 
over  time  to  reduce  profile  fluctuations.  They  can,  also  be  used 
to  determine  the  maximum  resource  levels  required  to  meet  project 
completion  dates. 

A simple  example  is  the  best  way  to  illustrate  the  applxca- 
tion  of  this  module.  Consider,  for  example,  the  simple  network 
shown  in  Fig.  2.4.33-3.  The  schedule  given  in  Fig.  2.4.33-4  was 
generated  by  setting  the  activity  start  times  equal  to  their  cri- 
tical path  early  starts.  This  schedule  requires  the  resource 
profile  shown  in  Fig.  2.4.33-4.  As  usual,  the  critical  path  early 
start  heuristic  gives  a schedule  that  is  very  front  loaded.  Ap- 
plication of  the  resource  leveling  module  delays  several  activities 
in  order  to  reduce  the  peak  resource  requirement.  The  new  schedule 
and  the  corresponding  resource  profile  is  given  in  Fig.  2.4.33-5. 

In  this  example,  the  least  squares  heuristic  reduced  the  sum  of 
. the  square's  from  2137  to  1261  units^  and  reduced  the  peak  level 
from  24  to  19  units.'  However,  this  heuristic  solution  is  not 
optimal.  For  example,  at  least  one  better  solution  is  illustrated 
in  Fig.  2.4.33-6.  For  this  schedule,  the  sum  of  the  squares  is 
1215  units2  and  the  peak  resource  requirement  is  only  15  units. 
This  example  clearly  illustrates  the  fact  that  heuristic  algo- 

righms  give  "good"  but  not  "optimal"  solutions. 
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F-ig.  2.4.ZZ-Z  Example  Project  Network 
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Fig.  2.4.33-5  Rescheduled  Using  RESOURCE _LEVELER 


Time  Time 

Fig.  2.4.33-6  "Hand”  Scheduled  Solution 


2.4.33-11 
Rev  B 


2.4.33.8  Implementation  Considerations 


Implementation  of  this  simple  heuristic  is  straightforward. 

The  only  significant  computation  is  the  calculation  of  the  minimum 
of  F|s^|.  One  approach  for  obtaining  this  minimum  is  outlined  in 
Fig.  2.4.33-7. 

When  the  individual  resource  quantities  are  different  by  more 
than  two  orders  of  magnitude  o\’’er  an  appreciable  segment  of  the 
schedule,  then  weighted  least  squares  are  required.  This  amounts 
to  adding  a weighting  matrix  to  the  least  squares  formula.  In 
most  normal  situations  scaling  the  resources  on  a percentage  basis 
is  adequate  to  ensure  that  each  resource  type  contributes  reason- 
ably to  the  sum  of  the  squares.  Percentage  scaling  gives  the 
diagonal  weighting  matrix 

W.  = 

X 

where 
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Fig.  2.4.33-7  (concl) 
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2.4‘.33.8  DETAILED  DESIGN 


This  module  levels  the  resource  utilization  profiles  (in  $PROFILES) 
for  the  set  of  jobs  input  in  $SGHEDULE,  This  is  accomplished  by  system- 
atically moving  the  jobs  around  on  the  time  line  within  their  given 
resource  and  temporal  relation  constraints.  The  selection  of  rescheduling 
time  points  is  based  on  minimization  of  the  sum  of  squares  of  the  resource 
usage  levels  over  time.  On  output,  ^SCHEDULE  and  $PRQFILES  will  contain 
revisions  to  reflect  the  scheduling  charges. 


2.4.33-15 

Rev  C 


2.4.33.9  INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 


$SCHEDULE 

$PROFILES 

$RE  S OURCE_S  AVE_AREA 
$JOB 

$JOB_INFO 

MODIFIED_SCHEDULE_F  LAG 
I__E  ARLIEST_SUCCE  S SOR_ 
START 
I__START 

I_JOB_START 

LATEST_START 

FUNCTIONjaiN  IMUM 

$POOL 

I,  J 

$JOB_PROFILES 
$ FAI  LURE_IN  DIG  ATOR 

$JOBID_TREE 

IjaESCHEDULE_TIME 

$TEMP_PROFILES 

I__THRESHOLD_FLAG 

FUNCTION 

$PROFILE 
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the  schedule  built  by  RESOURCE_ALLOCATOR 
tree  containing  all  pooled  resource  information 
temporary  storage  area  for  excess  resource 
information 

points  at  subnodes  of  $SCHEDULE 
summarizes  critical  path  information  of  $JOB 
if  equal  to  1,  indicates  job  can  be" rescheduled, 
indicates  the  earliest  end  time  of  all  successors 
of  $JOB 

temporary  variable  used  to  determine  I_EARLIEST_ 

SUCCESSOR_START 

start  of  $JOB 

difference  between  the  start  of  the  earliest 
successor  and  the  end  of  $JOB  plus  $JOB*s  start 
cumulative  sum  of  squares  of  $JOB_PROFlI£S 
points  at  pooled  resources  required  by  $JOB 
internal  counters 

contains  pooled  resource  information  about  $JOB 
indicates  the  time  after  which  resource  con- 
straint violations  are  allowed 
label  of  $JOB 

the  time  a job  can  be  rescheduled 
equivalent  to  $JOB__PROFILES 
ir.id;.cates  whether-or-not  contingency  level 
resources  can  be  allocated 
cummulative  sum  of  squares  of  $PROFILE 
points  at  subnodes  of  $TEMP_PROFILES 


$POOL_PROFII£ 

SUMJDF_SQUARES 

TOTAL 

SUM 


$JAB 

$RES013RCE_IABEL 


$TYPE 

$POOL_INFO 

$PARAMETER 

$INFO 

$JOB_RESOURCES 

$JOB_ID 

$CONDENSED 

ICRIT 

$LIST 

$LIST_EIEMENT 

$TRANSFER_INDICES 


contains  pooled  resource  information  for  a 
given  resource 

cumulative  totals  of  SUM  for  each  Interval 
in  $POOL_PROFILE 

cumulative  totals  of  resource  quantities 

2 

equals  the  product  of  TOTAL  and  the  interval 

length  of  the  $POOL_PROFILE 

points  at  subnodes  of  $SCHEDULE 

keeps  the  labels  of  resources  in  $JOBLIST  so 

that  the  resource  information  can  be  returned 

to  its  original  state  in  $ JOB LIST 

points  at  the  subnodes  of  $RESOURCE_SAVE_AREA 

contains  condensed  resource  information. 

temporary  storage  for  condensed  resource 

information  before  being  put  into  $POOL_INFO 

points  at  subnodes  of  $POOL 

points  at  subnodes  of  $RESOURGE__SAVE_AREA 

contains  label  of  $jOB_RESOURCES 

intermediate  tree  in  the  return  from  condensed 

resource  information  to  original  state 

index  for  1 to  NUMBER__0F_CRITER1A 

contains  the  list  to  be  ordered  by  different 

criteria 

points  to  the  subnodes  of  $LIST 

tracks  the  indices  of  the  variables  in  $LIST 

for  ordering  purposes 
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I_TRANSFER_INDEX 

$NEW_LIST 

$IN_USE 

$POOL__PROFILE 

I_CHECK_TIME 

NUMBER_OF_UPDATES 

$MODE 

$JOB__INTERVAL 

I_START 

I_END 

QUANTITY_DELTA , 

$ INTERVAL 
NLAST 

$NEW_INTERVAL  ' 

$INTERVAL1 

$INTERVAL2 

I_POINTER 
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equals  the  value  of  $TRANSFER^INDICES 

contains  the  ordered  $LIST 

the  in  use  portion  of  the  current  resource 

contains  the  resource  profile  for  a given 

resource 

contains  the  time  in  $FAILURE_INDICATOR 
equals  2 if  contingency  checks  are  to  be  made, 
equals  1 if  not  the  case 

reflects  the  user  choice  to  search  contingency 

levels  of  resources  or  not 

points  at  the  subnodes  of  $POOL 

the  sum  of  I__JOB_START  and  the  start  of  the 

resource  availability  in  $POOL 

the  sum  of  I_JOB_START  and  the  end  of  the 

resource  availability  in  $POOL 

the  initial  quantity  of  the  resource  in  $POOL 

being  processed 

the  inuse  portion  of  $POOL_PROFILE 
the  number  of  subnodes  of  $INTERVAL 
equivalent  to  $NULL,  used  to  insert  null  nodes 
onto  $ INTERVAL 

calling  argument,  containing  interval  information 
and  resources  to  be  updated  by  QUANTITY_DELTA 
if  it  is  not  empty,  then  its  associated 
quantity  is  taken  as  the  initial  quantity  of 
$INTERVAL1 

pointer  which  is  decremented  if  $INTERVAL1  and 
$INTERVAL2  can  be  combined. 


2.4.33.10  COMMENTED  CODE 


RESOURCE^LEVELERI  PROCEDURE  (SSCHEDULE*  SPROFILES) 
OPTIONS(EXTERNaL) I. 


/•  */ 

/»  THIS  MODULE  LEVELS  THE  RESOURCE  UTILIZATION  PROFILES  (IN  */ 

/^^  SPROFILES)  FOR  THE  SET  OF  JOBS  INPUT  IN  SSCHEDULEo  THIS  IS  #/ 

/*  accomplished  By  systematically  moving  the  jobs  around  ON  the  */ 

time  line  within  their  given  resource  and  temporal  relation  4/ 

/*  constraints,  the  selection  of  rescheduling  time  points  is  4/ 

/•  Based  on  minimization-  of  the  sum  of  squares  of  the  resource  4/ 

/*  usage  levels  over  time,  on  output?  sschedule  and  SPRoFILES  4/ 

/*  WILL  CONTAIN  RfVISIONS  TO  REFLfCT  THE  SCHEDULING  CHANGES,  4/ 

/*  4/ 


DECLARE  J5FA IlURE.INDICATOR, FUNCTION, FUNCTIOnIMINIMUM? 

I*I_EaRL1EST_SUCCESS0R_START,1_J0B..START, 
I_RFScHEDULE„TIMf,I_START«S  INTERVAL  »J»SJ0B,SJ08_INF0,’ 
$J0B.PR0FILES,LATEST_START»M00IFIE0_SCHE0ULE^FLAG, 

SPOOL ♦$PROFIl'E,$rESOURCe1sAVE„AREA,$SUCCESSOR, SUM, 
LOCALIINFINITY,  fNILL,  SJ08ID_TREE, 

SUM.OF_SQUARES,$fEMP_PROFlLES,TOTAL*TOTAL„QUAMTlTY  LOCAL  I 
SNILL  = SNULL  ; 

LOCALIiNFINITY  = 16000  « 

/*  THIS  CODE  CONDENSES  THE  DaTA  STRUCTURE  OF  SSCHEDULE  TO  InCReASF  4/ 
/•  the  efficiency  OF  mode  ACCESSES  In  THE  REST  OF  THE  PROGRAM,  4/ 

call  CONDENSe1reSOURCE_INFoRMATION (SSCHEDULE, $RESOURCE„SAVE_AREa)  I 
DO  FOR  AlL  subnodes  OF  SSChEDULE  USING  SJOB  I 

Graft  sjob.temporal_relation«successor  at  sjob^info, successor  i 
graft  SJOB. Slack, total  at  sjob_info,total_slack  i 
graft  SJOB. JOB.INTERVAL.START  at  SJOB_INFOoSTART  I 
graft  SJ08.JOB«INTERVAL«END  at  SJOB.INFO.END  I 
call  COMBINE1tREFS($JOB^ info, SJOB)  f 

END  I 

/♦  NOW  The  sum  of  squares  data  is  computed  for  each  usage  intervaI'  */ 

/*  AND  totaled  for  each  POOL  BFING  CONSIDERED,  4/ 

do  for  all  subnodes  of  SPRnFiLES  USING  SPROFILE  ? 

CALL  COMPUTE1sUm1oF.«SQUaRES(SPR0FILE) f 
end  I 

smootm.resource_profile » 

modified_schedule...flag  b 0 ; 

/»„»««*«««»««««#»««« 

ORDER  SSCHEDULE  BY  END,TOT4l1SLACK  | 

•«»««»«*«««««»«»/ 

CALL  SCHEDULE..ORDER  (SSCHEDULE)  » 

/*  EXAMINE  each  JOB  IN  THE  SCHEDULE  TO  DETERMINE  IF  IT  CAN  BE  4/ 

/*  rescheduled  at  a later  time  to  ACHIEVE  A MORE  LEVEL  RESOURCE  4/ 

/*  USAGE  PROFILE*  4/ 

DO  FOR  ALL  SUBNODES  OF  SSChEDULF  USING  SJOB  S 
IF  sjob.total.slack  > 0 

THEN  DO  t 

/•  DETERMINE  THE  SET  QF  TIMES  AT  WHICH  RESCHEDULING  CAN  BE  DONE  4/ 
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/♦ 


/* 

/* 

/* 

/* 


/* 

/* 


without  violating  any  temporal  relation  constraints,  #/ 

IF  $J0B.SUCCESS0R(EIRST)  IDENTICAL  TO  SNULL  , , _ 

Then  I EARLIfST^SUCCESSOR.START  =SSCHEDULF(FIRST) .ENHJ 
Else  do  I l’‘EARLlESti.SUrrESSOR.START«LOCAL_INFlNTTYt 
DO  FOR  ALL  SUBNOOES  OF  S J08.SUCCESSOR  USING  . 

SSUCCESSOR  » 

I STaRT  = SSCHEDuLE, W (SSUCCESSOR) ^STaRT  I 
IF  rSTART  < I.EaRLIEST-SUCCESSOR_STARJ  _ 

Then  i1earlIest_successor_start  « i^^staRT  i 
END  I 


END  I 

I JOB.START  a SjOB, START  < 

latest  start  = T-.EARLIEST-.SuCCESSOR«START  - sjob.^nd 

♦ I.J0B_START  I 


*/ 

«/ 


IF  LATEST^START  > I_J0B.START 

determine  the  set  of  times  at  which  RESCHEOIILINQ  CAN  RE  DONE 
without  violating  any  resource  constraints, 

then  do  ? FUNCTION.MINIMUM  a 0.0  ? I = 0 I 
FIRST*  RESOURCES  FOR  THIS  JOB  MUST  BE  DEALLOCATED  TO  MAKE  f/ 

SPROFILES  LOOK  AS  THOUGH  THIS  JOB  HAS  BEEN  UNSCHEDULED.  «;/ 

DO  FOR  ALL  SUBNODES  OF  SJOB. RESOURCE  USING  SPOOl  I 


I * !♦!  I 

GRAFT  INSERT  fPROFiLES.WLABEL (SPOOL)  BEFORE  ^ 

$J0B_PR0FIlES(FIrST) I 
functionIminimum  = FUNCTI0N_MINIMUM  ♦ 

SJOB-PROFILES (FIRST) .SUM^OF^SOUARESI 

SFAli’URE' indicator  = latest^start  ♦ 

SPOOL (LAST) .FND  « 


SJOBlO_TRFE  a LABEL(SJOB)  I 

call  updateIpool.levels 

( SPOOL »SJOBID_TREEtSJOB_PROFlLES. 
T.JOB-START*O.Of$FAILUREllNDICATnR).,l 
IF  SfAILURE^INDICATOR  not  IDENTICAL  TO  sNUi  I. 

. Then  do  T J = i i 

DO  FOR  ALL  SUBNODES  OF  SJOB.RESOUPCE 

USING  SPOOL  t 
IF  I*J  THEN  60  TO  CHECK_NEXTl'.jOB  t 
SJOBiD'TRFE  a LABEL (SJOB)  % 

call  UPDATE  POOL^LEVELS (SPOOL. 

S JOB ID_TREE.SJ0B.PR0F ILFS  •> 

I_J08_START.0.1.SNli'L>  I 

J a J+1  I 
END  I 
END  ? 

END  j 

T RESCHEOULeItIME  = I_JOB_START  I 
rescheduling  of  this  JOB  TS  attempted  at  each  FEASIBLE  TIME 
POINT  LATER  THAN  THE  JOBS  CURRENT  SCHEDULED  START  TIME.  */ 

DO  lal.jOR^STARTfl  TO  LATEST.START  I 
STEMP„PR0EILES  = SJOB.PROFILES  ? 

J a n » 
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DO  FOR  ALL  SUBNODES  OF  $JOB. RESOURCE  USING 

SPOOL  I 

J ■ J*1  I 

IF  STEMP.PROFILES.#LABEL<SPOoL) . available, C0NTlN6ENCY(FlRST)»$NUiT 
THEN  I^THRESHOLO«FLAG«0| 

ELSE  I.THRESHOLD-FLAOwII 

SjOBIdItREE  « label (SJOB)  I 
Call  UPDATEJ’OOL.LEVELS(SPOOL*$JOBlD'fpEE,’ 
STENPjpROFILES# I f T THRESHOLO.FLAS* 1 , 
SFAILURE^INOICaTOR) I 

IF  SFAILURE-INDICATOR  NOT  IDENTICAL  TO 

sNUii' 


THEN 


DO  I 

graft 

60  TO 
End  I 


INSERT  SPOOL  BEFORE  SjOfl,’ 

resource (FIPST) I 
CHECK^NEXT^TIME.POINT  I 


End  I 

/♦  SINCE  THE  ABOVE  RESCHEDULING  ATTEMPT  WAS  SUCCESSFUL*  THE  SUM  OF 
/♦  SQUARES  DATA  IS  CaLCULATEo  TO  SEE  IF  THIS  WOULD  PROVIDE  AN 
/♦  IMPROVED  schedule. 

function  = 0,0  I 
DO  FOR  All  subnodes  OF  stemp^profiles  using 

SPROFTLE 

Call  compute_sumuof_squares(sprofile)  i 
Function  » function  ♦ 

SPR0FILE*SUM.0F_SQUARES  I 

End  I 

IF  Function  <*  function^minimum 

Then  do  ; functionIminimum  » function  i 
i.reschedule.time  s I I 

end  I 

C«ECK.NEXT_TI?4E_P0INT|  end  I 
/*  THE  JOB  BEING  CONSIDERED  IS 
/*  ORIGINAL  start  TIME  OR  AT  A 

/♦  level  resource  usage  profile. 

IF  I.REsCHEDULE^ItIME  = LATEST^START 

then  graft  STEMP.PROFILES  at  SJOB.PROFILES 
ELSE  DO  FOR  ALL  SUBNODES  OF  SJOB, RESOURCE 

USING  SPOOL 

IF  S JOB.PROFILES.WLABEL (SPOOL) .A VA ILABLE.CONT INGENCY (FIRST )=$NULL 
THEN  I.THRESHolD  FLA6*0I 


#/ 
• / 
#/ 


NOW  RESCHEDULED*  EITHER 
LATER  TIME  resulting  IN 


AT  ITS 
A more 


#/ 

*/ 

*/ 


t 


ELSE  I^THRESLSLD_FLA6*II 


SJOBIO^TREE  a label (SJOB)  | 

CALL  UPOATE^P0OL.LEVELS (SPOOL* 

SJOBtD„1REE*SJOB.PROFiLES* 
I.RESCHEOULE.TIME* 
I.THRESH0LU«FLA6*1*SNILL)  I 
CALL  C0MPUTE.SUM^0F.SQUARES 

( SJOB^PROF ILES , #L ABEL ( SPOOL ) ) 

END  I 


2.4.33-21 
Rev  C 


•tn. 


IF  I.REf?CHEOULElTlME  iIjOB.START 
THEN  DO  I 

modifieoIschedule^flag  s 1 I 
sjoB. start  = I.RESCHEOULE.TtmE  I 
SJOB.END  * SJOB.END  ♦ I.RESCHEDULeIttME  - 

i.jobIstaRt  I 


END  I 

CALL  C0m8INe1tREFS($J0B_PR0FILES#SRR0FILES)  I 
END  I 

End  I 

CHECK.NEXT.JOB: 

END  I 

/♦  IF  ANY  OF  THE  JOBS  WERE  MnVED  AS  A RESULT  OF  THE  LAST  LEVELING  »/ 


/#  PASS*  make  another  pass  TO  SEE  IF  A MOPE  LEVEL  SCHEDULE  CAN  BE  #/ 

/*  attained, 

IF  MOOIFIED.SCHEDUlE.FLAG  -a  0 THEN  GO  TO  SMOOTH.RESOUPCE«PROFTLE 
/•  NOW  THE  SUM  OF  SQUARES  DATA  IS  ELIMINATED  FROM  SPROFILES  AND  * 

/*  SSCHEDULE  is  RESTORED  TO  ITS  ORIGINAL  FORM,  * 


DO  FOR  ALL  SUBNOOES  OF  SPRoFiLES  USING  SPROFILE  I 
PRUNE  SPROFILE, SUM.OF.SOUARES  I 

DO  FOR  ALL  SuBNOnES  OF  «PROfILE, IN.USE  USING  SINTERVAL  I 
PRUNE  STnTERVAL.SUM  I 
END  » 

end  I 

/**^##*****^M^*»#^MH^* 

ORDER  SSCHEDULE  BY  -START*-DURATI0N  » 

****»»**«***#<»«•#*#/ 

CALL  FINAL.OrdEr (SSCHEDULE)  I 

CALL  RESTORE.PESOURCE.INFOpMATION(SSCHEDULE*SRESOURCE.SAVE JVPEA)  I 
DO  FOR  ALL  SUBNODES  OF  SSChEDULF  USING  SJOB  I 

GRAFT  SJ08, SUCCESSOR  AT  SJOB, TEMPORAL.RELATION, SUCCESSOR  I 

graft  sjob.totalIslack  at  SJOB. slack, total  I 
graft  SJOB, start  at  sjob.jobIinterval, start  I 
graft  SJOB, end  at  SJOB, job' interval, end  I 

END  I 


compute.sum.ofIsouares:  procedure  (SPOOLIpROFILE)  » 

/♦  THIS  procedure  recomputes  the^sum  of  squares  data  for  a p/ 

/*  resource  USaGE^ profile  (SPOOL_PROFILE,IN.USE) , p/ 

DECLARE  SUM_oF_SQUARES*  StNTERVAL*  SJAB*  T0TAL*SUM  LOCAL  I 
SUM.OF.SQUARES  a 0,0  I 

do  For  all  subnooes  of  spoolIprofIle-in.use  using  sinteRval  » 

TOTAL  a 0,0  I 

DO  FOR  ALL  SUBNODES  oF  SINTERVAL. USAGE  USING  SJAB  I 
TOTAL  a total  ♦ S jAB,QUANTl TY  I 
END  I 

STNTERVAL, TOTAL  * TOTAL  I 
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SUM  ■ TOTaL*TOTAL*(S!NTERVAL.END  - SINTERVAL. START)  I 
$ INTERVAL. SUM  ■ SUM  » 

SUM^OF.SQUARES  a SUm|of_SOUARES  ♦ SUM  I 

end  I 

Spool PR0FILF.SUM^0F«SQUARES  s SUM„f»FlSQUARES  I 

END  I /«  COMPuTE_SUM«OF«SOUARFS  */ 

SCHEDULE^OROERI  PROCEDURE  (SScHEOULE)  I 
/*  ORDER  SSCHEDUlE  BY  ENDf  TOTAL^SLACK 

DO  FOR  ALL  SUBNOOES  OF  SSCHEOUlF  USlNS  SJOB  I 

graft  insert  sjob.end  Before  sjob (first)  i 
• graft  insert  sjob. TOTAL'  slack  BEFORE  *JOB{FIRST)  I 
END! 

NUMBER.OF^CRITERIA  =21 

CALL  MULTI«CRlTERlAlORDER(*SCHEDULE*NUMaER_OF«CRITERIA.l)  I 
END?  SCHEDULE^ORDEP 

FINAL_0RDER»  procedure  (SSrHEOi  I 

/* 

/♦  orders  ^schedule  by  lowest  start  and  duration  for  output 
declare  SSCHEd„JOB  local  I 

DO  FOR  ALU  SUBNODES  OF  SScHEO  USING  SSCHED^JOB  $ 

Graft  insert  ssched_job, start  before  ssched.jobifirst)  i 

SSCHED^JOB.DUR  a SSCHED< J08.FND  - SSCHED_JOB • START  ) 
graft  insert  5SCHED.JOB.OUR  before  fSCHED^JOB (FIRST)  ) 
ENDr 

Call  MULTI.CRlTERlA.ORDER(SSCHFDt  2*  -1  ) I 
DO  FOR  ALL  SUBNODES  OF  SScHED  USING  SSCHEdIjOB  I 
PRUNE  SSCHEDIJOB.DUR  ? 

ENO» 

ENOI  /»  FINaL^ORDER  */ 

END!  /*  RESOURCE.LEVELER  */ 


2.4.34  HEURISTIC_SCHEDULING 
PROCESSOR 


2.4.34  HEURISTIC_SCHEDULING_PROCESSOR 
2.4.34.1  Purpose  and  Scope 

This  processor  heuristically  schedules  the  class  of  projects 
definable  by  precedence  networks.  Activity  start  times  are  se- 
lected in  an  effort  to  heuristically  minimze  project  duration 
while  satisfying  resource ' constraints . A resource  leveling  facil- 
ity is  also  provided  to  improve  a previously  obtained  heuristically 
"short”  project  duration.  Thus,  heuristic  scheduling  of  the 
shortest  project  duration,  consistent  with  both  normal  and  con- 
tingency resource  availabilities,  is  determined  by  the  RES0URCE_ 
ALLOCATOR.  Then  using  this  schedule  as  a basis,  the  RES0URCE__ 
LEVELER  reduces  to  a heuristic  minimum  the  day-to-day  variation 
in  utilization  levels  of  the  various  resources  while  preserving 
the  project  duration.  The  combination  of  a forward-pass  resource 
allocation  to  determine  the  minimum  feasible  project  duration 

j 

followed  by  a backward— pass  resource  leveling  to  smooth  out  the 
resource  loading  is  a technique  frequently  used  by  practical 
schedulers.  The  two-phase  procedure  provides  an  effective  look- 
ahead capability  without  the  need  for  the  usual  complicated  logic. 

The  processor  addresses  the  broad  class  of  high-level  schedul- 
ing problems  expressable  as  projects.  By  a project  is  meant  a 
collection  of  activities  each  with  a specified  duration,  set  of 
predecessor  activities,  and  resource  requirements.  A predecessor 
of  a given  activity  is  defined  as  a second  activity  that  must 
precede  the  former  by  an  arbitrary  interval.  The  precedence  re- 
lations of  such  projects  are  described  graphically  by  precedence 
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networks.  Each  activity  can  require  multiple  resources  at  utiliza- 
tion rates  that  vary  with  time.  The  resource  pool  structure  is 
made  versatile  by  providing  both  normal  and  contingency  availability 
levels . 

Unfortunately,  some  scheduling  problems  have  temporal  rela- 
tions among  their  activities  that  cannot  be  described  in  terms 
of  simple  predecessor  sets  even,  with  the  addition  of  dummy  jobs. 

The  most  prominent  class  of  such  problems  are  those  that  must  have 
a fixed  interval  between  two  activities.  To  convert  such  a problem 
to  the  project  format,  the  two  jobs  are  usually  lumped  into  a single 
composite  job.  However,  the  predecessors  and  successors  of  the 
original  component  jobs  must  then  be  made  predecessors  and  suc- 
cessors, respectively,  of  the  new  composite  job.  This  ploy  may 
not  yield  and  accurate  representation  of  the  original  situation. 

Most  other  forms  of  general  temporal  relations  can  be  modeled 
in  terms  of  precedence  sets  by  the  simple  addition  of  dummy 
activities,  which  require  no  resources.  For  example,  the  relation- 
ship that  the  start  of  activity  B follow  the  end  of  activity  A by 
at  least  an  interval  of  length  "a,”  can  be  modeled  by  placing  A 
in  the  predecessor  set  of  a dummy  activity  D,  that  has  a duration 
"a"  and  requires  no  resources,  while  placing  D,  in  turn,  in  the 
predecessor  set  of  A.  Another  simulation  alternative  would  be  to 
alter  the 'definition  of  activity  A to  include  the  idle  interval 
of  length  "a."  In  fact  most  high-level  scheduling  problems  can 
be  reasonably  well  represented  by  a precedence  network.  Reason- 
ably accurate  modeling  can,  however,  require  a great  deal  of 
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ingenuity.  Furthermore,  questions  that  arise  in  modeling  the 
project  as  a precedence  network,  frequently  shed  light  on  the 
entire  scheduling  problem. 

Burman  (Burman,  72)  has  suggested  a sophistication  of  the 
ordinary  precedence  network  that  would  permit  the  simple  repre- 
sentation of  all  temporal  relations  among  activities  and  events. 
Indeed,  a somewhat  more  involved  critical  path  algorithm  can  be 
developed  to  generate  critical  path  data  for  his  sophisticated 
networks.  Unfortunately,  however,  the  new  networks  hopelessly 
complicate  any  heuristic  scheduling  process.  As  is  so  often  the 
case  in  problem  solving,  it  is  far  easier  to  generalize  a problem 

than  to  solve  it. 

Basically,  what  Burman  has  done  is  to  identify  a new  type  of 
successor~the  closely-continuous  successor.  Such  a successor  must 
begin  at  the  instant  of  completion  of  its  predecessor.  To  see 
how  this  new  concept  facilitates  the  simulation  of  general  temporal 
relations,  consider  the  following  examples.  Consider  the  most 
difficult  case  of  two  activities  whose  respective  start  and  finish 
are  constrained  to  differ  by  a fixed  time  interval  with  the  suc- 
cessor activity  having  an  ordinary  second  predecessor  as  shown  in 
Fig.  2.4.34-1. 
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^S^ipll'septesentation  of  a General  Temporal  Belation  Using 
Closely -Continuous  Successors 


To  represent  this  temporal  relation  in  terms  of  closely- 
continuous  successors  one  has  only  to  introduce  a single  dummy 
activity  D requiring  no  resources  of  duration  equal  to  the  fixed 
interval  length  "a."  Activity  D is  then  made  a closely-continuous 
successor  of  activity  A and  B,  in  turn,  is  made  a closely  con- 
tinuous successor  of  D.  Activity  B is  made  an  ordinary  successor 
of  activity  C.  Consider  next  the  case  illustrated  m Fig.  2.4.34-2, 
wherein  one  activity  cannot  start  until  a second  activity  has 

started.  . 


Fiq . 2.4.34-2  ^ ^ 77  ■ 

Sample  Representation  of  a General  Temporal  RelaUon  Cs^ng 

Closely  Continuous  Successors 
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To  represent  this  temporal  relation,  one  need  only  Introduce 
a single  dummy  event  E.  Then  activity  A Is  made  a closely-con- 
tinuous  successor  o£  event  E while  activity  B is  made  an  ordinary 

successor . 

Although  the  closely-continuous  successor  concept  provides  a 
generalized  network  presentation  of  all  of  the  general  temporal 
relaUons,  no  simple  heuristic  procedure  can  be  devised  to  sched- 
ule such  a network.  Long  multibranch  trees  of  closely-continuous 
successors  of  a given  activity  have  to  be  scheduled  before  that 
activity  itself  can  be  scheduled.  This  considerably  complicates 
the  resource  allocation  logic  perhaps  to  the  point  of  diminishing 
returns.  Any  complications  in  a heuristic  procedure  must  be 
Justified  by  their  results.  Without  establishing  the  utxlity  of 
the  relatively  simple  resource  allocator  for  ordinary  precedence 
networks,  it  seems  pointless  to  build  a vastly  more  complicated 
allocator  for  generalized  precedence  networks.  Nonetheless,  in 
Subsection  2.4.34.7,  a proof  is  given  that  any  general  temporal 
relation  can  be  modeled  using  only  ordinary  and  closely  continuous 

successors  * 

This  module  has  the  capability  of  scheduling  interfacing  sub- 
networks. It  assembles  a user  supplied  master  subnetwork  and 
all  of  its  interfacing  subnetworks  into  a master  network.  All  the 
activities  of  this  master  network  are  to  be  scheduled  subject. to 
common  resource  availability  levels. 
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is  used  to  obtain  short, 


A time-progressive  heuristic  .program 
but  not  necessarily  minimal,  project  durations.  The  heuristic 
employs  a critical -path-based  priority  rule  tempered  by  a modify- 
ing heuristic  using  contingency  resource ‘thresholds . By  utiliz- 
ing late-start  time  as  the  priority  value  of  each  activity  or 
event,  a dynamic  priority  function  is  obtained  that  does  not  re- 
quire updating  each  time  a new  acticity  is  scheduled.  This  re- 
sults from  the  fact  that  the  late-start- date  of  an  activity  is 
independent  of  the  actual  scheduled  start  dates  of  any  of  its 
predecessors  as  long  as  none  of  them  are  delayed  beyond  its  late 
start  date.  Nonetheless,  the  late-start  date  does  represent  a 
good  priority  rule  in  terms  of  scheduling  the  least  flexible 
activities  first.  That  unscheduled  activity  with  the  earliest 
late-start  date,  other  factors  being  equal,  is  the  activity  most 
likely  to  lengthen  project  duration  beyond  the  critical-path  value. 
The  modifying  heuristic  is  activated  whenever  an  activity  cannot 
be  scheduled  before  its  late-start  date.  The  resource  that  pre- 
vents the  scheduling  of  the  activity  is  augmented  by  a user-input 
contingency  threshold  from  the  time  the  activity's  predecessors 
were  all  completed  until  the  activity  is  successfully  scheduled. 

Finally,  an  option  is  provided  for  leveling  the  resource 
utilization  profiles  via  a least  squares  heuristic  after  a tenta- 
tive initial  schedule  has  been  obtained  from  the  late-start-date 
heuristic.  The  leveling  procedure  involves  sequentially  consider- 
ing the  activities  in  order  of  latest  scheduled  finish.  A weighted 
sum  of  squares  of  the  resource  profiles  over  time  is  then  computed 
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for  each  activity  for  each  start  date  in  its  residual  float.- 
That  start  date  in  the  float  interval  is  selected  that  will  min- 
imize the  weighted  resource  sum  of  squares.  Two  underlying 
principles  motivate  this  heuristic  procedure.  First,  by  sequen- 
delaying  activities  considered,  in  order  of  their  latest 
scheduled  finish,  the  float  of  activities  with  earlier  scheduled 
finishes  can  only  be  increased,  thereby  improving  their  subse- 
quent scheduling  flexibility.  Second,  the  weighted  sum  of  squares 
of  the  resource  profiles  over  time  is  decreased  by  reducing  any 
jump  in  the  utilization  level  of  any  resource  from  one  time  in- 
terval to  the  next.  In  fact,  the  unconstrained  minimum  sum  of 
the  squares  is  achieved  when  all  the  resource  profiles  are  such 
that  the  utilization  levels  of  any  given  resource  in  each  time 
period  is  a constant. 

2.4.34.2  Modules  Called 
NETWORKJ\SSEMBLER 
RES0URCEJ\LL0CaU0R 
RESOURCEJ.EVELER  ' 

2.4.34.3  Module  Input 

1)  Network,  Critical  Path  Data  and  Activity  or  Event  Definitions 

($J0BSET) 
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IJOBSET 


2)  Resource  Definitions  ($PR0FILES) 

$PR0FILES 


3)  Interfacing  Event  Definitions  ($INTERFACE) 
$ INTERFACE 


(IDENTIFIER  OF  (IDENTIFIER  OF 

CONTAINING  SUBNET)  CONTAINING  SUBNET) 

4)  Resource  Leveling  Option  Indicator  (LEVEL) 
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2.4.34.4  Module  Output 


1)  Resultant  Project  Schedule  ($SCHEDULE) 


2)  Revised  Resource  Profiles  ($PR0FILES) 

Same  as  for  Module  Input. 

2.4.34.5  Functional  Description 

The  HEURISTIC_SCHEDULING_PROCESSOR  serves  as  an  executive  pro- 
cedure for  controlling  and  coordinating  the  entire  heuristic 
scheduling  process.  First  the  network  must  be  built  whose  activ- 
ities are  to  be  scheduled  sharing  the  same  common  resources.  By 
means  of  a call  to  the  module  NETWORK_ASSEMBLER,  the  user-specified 
master  subnetwork  and  all  of  its  interfacing  subnetworks,  as  de- 
tailed in  the  interfacing  event  definitions,  are  assembled  into 
the  desired  network*  Next,  the  RESOURCE _ALL0CAT0R  is  called  to 
schedule  the  activities  of  the  network  according  to  the  minimum 
project  duration  heuristic  procedure  described  above.  Earliest 
late-start  is  used  as  the  priority  function  for  each  activity. 
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If  an  activity  is  ddayad  beyond  xts  late“Stairt  date  because  of  a 


resource  shortage,  a modifying  heuristic  is  invoked  to  increase 
the  availability  of  the  deficient  resource  by  a user  input  con- 
tingency threshold.  If  the  user  does  not  request  any  resource 
leveling  effort  by  leaving  the  leveling  option  indicator,  LEVEL, 
unset,  the  heuristic  scheduling  process  ends  here.  Otherwise  the 
module  RESOURCEJ-EVELER  is  called  to  heuristically  reduce  to  a 
minimum  the  jumps  in  the  resource  utilization  rate.  The  heuristic 
operates  by  considering  the  activities  in  order  of  latest  sched- 
uled finish.  The  weighted  sum  of  the  resource  profiles  squares 
over  time  is  then  computed  for  each  possible  start  time  of  the 
activity  under  consideration  within  its  remaining  total  float. 

That  start  time  is  selected  that  minimizes  the  sum.  When  all  the 
activities  have  been  considered  for  delay,  the  leveling  effort 
is  complete  and  the  heuristic  scheduling  terminates.  The  simple 
macrologic  for  the  processor  is  illustrated  in  the  functional  block 
diagram.  M re  detailed  information  on  the  resource  allocation 
and  leveling  heuristics  can  be  found  in  the  respective  specifications 
for  the  modules,  RESOURCE _ALL0CAT0R  and  RESOURLE_LEVELER. 
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2.4.34.6  Functional  Block  Diagram 
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2.4.34.7  Imp lament at  Ion  Consideration 


The  salient  feature  of  precedence  network  methods  development 
has  been  the  appearance  of  a tremendous  number  of  elaborate  com- 
puterized heuristic  routines  for  constrained-resource  scheduling. 

Most  of  these  computer  codes  have  been  developed  by  organizations 
for  internal  and  external  use  on  a proprietary  basis.  Hence,  their 
operating  details  are  not  available  in  the  open  literature.  How- 
ever, some  are  available  which  disclose  their  ope^cating 
principles.  Table  2.4.34-1  presents  a sampling  of  the 
more  prominent  programs  known  to  be  available  in  the  USA  and 
United  Kingdom.  Each  program  produces  a wide  variety  of  resource- 
and  activity— oriented  reports  in  both  tabular  and  graphic  form. 

For  many  applications,  the  complete  capability  of  any  of  the 
commercial  systems  is  not  required,  A smaller  more  specialized 
system  could  be  built  around  the  basic  modules  outlined  above.. 

Such  a flexible  system  could  then  evolve  to  meet  the  user’s  ever- 
changing  needs. 

In  closing  this  section,  the  claim  that  any  generalized 
temporal  relation  can  be  expressed  in  terms  of  ordinary  and  closely— 
continuous  successors  with  only  the  addition  of  dummy  activities 
will  be  verified.  Recall  the  generic  form  of  a generalized  temporal 
relation 
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Table  2.4.34-1 

Sample  ChcOL'uo'tens t/i-as  of  oOme  Comtnex'n'Lally -Available  Computer  Px'ogy'ains  with  Conty'ained- 
Reaourae  network  Scheduling  Capabilities 


Program  Name  and 
Company  Responsible 

Features 

CPM-RPSM  (Resource 
Planning  and  Scheduling 
Method) 

CEIR,  Inc 

2000  to  8000  jobs  per  project,  4 resource  types  per  project, 
26  total  variables  or  constraint-resource  limits,  job 
splitting  allowed,  job  start  or  finish  constraints  allowed. 
Uses  fixed  scheduling  heuristic. 

TCT  1900  Series  PEWTER 
(PERT  without  Tears) 
International  Computers, 
Ltd 

Multiproject  capability,  60,000  activities,  60  resources 
per  activity,  125  resources  per  project,  flexible  updating 
and  reporting  options.  Uses  advanced  resource  allocation 
heuristic,  enabling  user  to  invoke  input  resource  con- 
tinegency  thresholds.  Levels  resources  with  a separate 
heuristic.  Employs  a network  condensation  capability  to 
accurately  process  large  networks  in  pieces. 

MSGS  ("Management  Schedul- 
ing and  Control  System") 
McDonnell  Automation  Co, 

Multiproject  capability  (25  projects),  18,000  activities, 
12  resource  types  per  activity.  Many  flexible  assumptions 
of  job  conditions,  easy  updating.  Allows  project  costing 
and  includes  report  generation.  Scheduling  heuristics  are 
based  on  complex  priority  function  approach  controllable 
by  user. 

PMS/360  (Project  Manage- 
ment System) 

IBM  Corporation 

A large  complex  management  information  system  consisting 
of  four  main  modules  (of  which  resource  allocation  is 
one).  Handles  activity-on-arrow  or  precedence  diagrams; 
up  to  225  multiple  projects  allowed  with  32,000  activities 
and  250  resource  types.  Numerous  costing,  updating,  and 
report  options.  A choice  of  sequencing  heuristics  is 
provided  . 

PPS  IV  (Project  Planning 
System) 

Control  Data  Corporation 

2000  jobs  per  project,  20  resource  types  per  job  and 
project,  multiple  or  single  projects,  allows  overlapping 
jobs,  resource  costing,  and  progress  reporting.  Will 
also  do  resource  leveling  with  fixed  duration.  Resource 
priorities  may  be  specified,  and  multishift  work  is 
allowed.  Uses  one  fixed  heuristic  procedure. 

PROJECT/2 

Project  Software,  Inc 

Allows  50  multiple  networks,  32,000  jobs,  several  hundred 
resource  types.  Includes  automatic  network  generation 
for  repetitive  sequences,  easy  updating,  and  many  cost 
analysis  features.  Choice  of  sequencing  heuristics  speci- 
fied by  user.  Handles  actlvity-on-arrow  or  activity-on- 
node  input. 

PA6B  o 
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where  i and  j are  any  activities  or  events  in  the  project  and  "s" 
denotes  a start  time  while  "f"  signifies  a finish  time.  But, 
because  s^  ~ ^i  ~ *^i  ^ ^j  ’ relation  [1]  can  be 

simplified  to 


where  k is  a constant  of  arbitrary  polarity.  From  the  three  re- 
lational operators  three  basic  cases  can  be  identified.  These 
will  be  considered  in  turn. 


d = k - d, 
m 3 


[5]  Case  II  f . s,  + k 

[6]  s.  + d.  ^ + k 

[7]  ^ ^2  " 

Relation  [7],  however,  has  already  been  modeled  as  a general 

precedence  relation  in  Case  I if  the  labels  i and  j are  inter- 
changed . 

[8]  Case  IIIA  f , = s . + k and  k d 

'■  , 1 j J 


f.  =s  =s.  +d,+d 
1 n j j m 


Thus,  any  general  temporal  relation  betx<;een  two  activities,  i and 
j,  can  be  represented  in  terms  of  closely  continuous  and  ordinary 
successors  without  redefining  or  combining  any  activities.  Only 
new  dummy  activities  need  be  introduced.  Hence,  the  identity  of 
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all  the  original  activities  is  maintained  so  that  an  ordinary 
predecessor  or  successor  relation  can  be  represented  as  usual. 

2.4.34.8  References 

IBM,  Fvooeot  Management  System  IV  Network  Processor  Program  Descrip 
tion  and  Operations  Manual^  Publication  SH20-0899-1-,  1972, 

ICT  1900  Series  PEWTER  (PERT  without  Tears),  ICT  Technical  Publi- 
cations Group,  London  1967. 

Burman,  P.  J. : Precedence  Networks  for  Project  Planning  and  Con- 

trol. McGraw  Hill,  London,  1972.  • 
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2.4.34.9  detailed  DESIGN 


This  module  heuristically  schedules  the  broad  class  of  scheduling 


problems  definable  by  precedence  networks.  It  serves  primarily  as  an 
executive  routine  calling  NETWORK.ASSEMBLER,  PREDE'CESS0R_SET_INVERTER, 
CRITICAL  PATH  CALCULATOR  and  then  RES0URCE_ALL0CAT0R.  The  user  has 
the  option  to  call  RESOURCE_LEVELER  as  well. 

2.4.34.10  INTERNAL  VARIABLE  AND  TREE  NAME  DEFINITIONS 


$ INTERFACE 


- Contains  the  network  interfacing  event  definitions 


$J0BSET 


Contains  the  master  subnetwork  vjhich  contains 
the  set  of  jobs  that  are  to  be  scheduled 


LEVEL  RESOURCE_FLAG  - A flag  used  to  indicate  whether  or  not  RES0URCE__ 
"■  LEVELER  is  to  be  called 


$PR0FILES  - Contains  all  resource  pool  profile  data 

$SCHEDULE  “ The  final  schedule  output  by  the  module  containing 

absolute  time  and  resource  assignments 

$SUBNET  SET  ■ Contains  the  names  of  the  subnetworks  eliminated 

” by  NETWORK_ASSEMBLER,  when  it  built  the  master 

subnetwork 


2.4.34.11  MODIFICATIONS  TO  FUNCTIONAL  SPECS  AND/OR  STANDARD  DATA  STRUCTURES 
It  was  decided  that  $SUBNET_SET  should  also  be  an  output  of  this 
module.  Since  NETWORK_ASSEMBLER  builds  it  anyway,  it  takes  no  extra 
effort  to  return  this  information  to  the.  calling  program.  For  better 
readability,  the  name  of  the  resource  leveling  option  indicator  was 
changed  from  LEVEL  TO  LEVEL_RES0URCE_FIAG. 
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2.4.34.12  COMMENTED  CODE 


HiURISTiC.SCHEOULiNG.PROCESSORJ  PROCEDURE 

/♦♦***«********#*#tt****<HHH»«H»##««fl.*4H»«fl.**#iHHHHHHHHH»**tt*<HMH»***<t*4^**^/ 

'*  # 

/♦  THIS  MODULE  HEuRISTICALLY  SCHEDULES  THE  BROAD  CLASS  OF  SCHEOUL-  • 

/*  ING  problems  Definable  by  precedence  networks,  its  input  and 
/»  output  parameters  are  described  below:  ;> 

/*  SJOBSET  r the  Set  of  jobs  that  are  to  be  scheduled  #/ 

/*  sinterfage  — the  network  interfacing  event  definitions 

/•  LEVEL^RESoURCE^FLAG  A FLAG  INDICATING  WHETHER  OR  NOT  ♦/ 

/«  RESOURCE  LEVELING  IS  TO  BE  DONE  */ 

/*  SPROFIlES  CONTAINS  ALL  RESOURCE  POOL  PROFILE  DATA 

/*  $SUBNET„SeT  «-  CONTAINS  THE  NAMES  OF  THE  SUBNETWORKS  USED  */ 

/*  TO  BUtLD  THE  MASTER  SUBNETWORK 

/*  SSCHEDULE  - — - A HEUrISTICALLY  MINIMUM  DURATION  SCHEDULE  «/ 

/*  WITH  aSSOLi’iTE  time  AND  RESOURCE  ASSIGNMENTS  */ 

♦/ 

(SJoBSETt  sinterface*  smaster1subnfT»id, 

LEVEl^RESOURCE^FLAQ*  SPROEli'ES*  SSUBNET.SET*  SSCHEOui'E) 
OPTTONS(EXTERNflL) I 
declare  $TEMP  locali 

call  NETWORK_ASSEMBLER(SJOrSET.SINT^RFACE*SMASTER.SUBNET«ID, 

SSURNETiiSET)  I 

CALL  PREDECESSOR..SET_INVERTEp($JORSET) I 
CALL  CRlTICAL_PATH«CALCULATnR(SjOBSET# 

#(Smaster.subnft1id>  *STFMP) J 

GRAFT  STEMP  AT  SJOBSET.# ($MaSTER1SUBNET_ID) I 
WRITE  ’OUTPUT  *SUBnET_SET  AND  SJOBSET  aETER  ASSEMBLING  THE  NETWORK  ♦ » 
WRITE  SSUBNET.SET  % 

WRITE  SJOBSET  I 

CALL  resource_allocator 

(SJOBSET.# ($MASTER1sUBmET„ID) ♦ SPROFILES t SSCHEDui ’E)  X 
WRITE  'OUTPUT  SSCHEDULE  AND  SpROFRES  A^TER  ALLOCATION  • I 
WRITE  SSCHEDULEt  SpROFILESi 

IF  levelIresource^fLag  -•«  0 

Then  call  resource_leveler($schedule»$profiles)  i 

END  HEURISTIC1_SCHEDULIN6_PR0CfSS0R  \ 
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2,4.35  GUB_LP 


2.4.35  GUB  LP 


2.4.35  GUB_LP 

2.4.35,1  Purpose  and  Scope 

Generalized  upper  bounding  (GUB)  is  a simplex  type  algorithm 
designed  specifically  for  linear  programs  that  contain  large 
numbers  of  convexity  constraints.  The  principal  advantage  of 
GUB  for  this  class  of  problems  is  that  it  requires  a significantly 
smaller  working  basis . Use  of  this  smaller  working  basis  reduces 
fast  core  memory  requirements  and  increases  the  computational 
speed  by  nearly  an  order  of  magnitude  for  GUB  problems. 

GUB  applies  to  IPs  of  the  form:  minimize  u°,  subject  to: 


[1] 


[2] 


m rows 


P rows 


N 

o 

A.  "O 


P % 


u + S a.x-^  + S 


3=1 


p=l  k-1 


i k , i . TO 
a,  X ^b  , x = l,/,...,m 
kp  p 


Pp 


x„  = 1,  p = 1,2, . . . ,P 


u"^ , u‘ 


0, 


In  the  above  formulation,  u denotes  the  logical  variables 

(slack,  surplus,  and/or  artifical)  augmented  to  transform  the 

i-th  constraint  into  an  equation,  for  j=l,,..N^  denotes  the 

structural  variables  that  are  not  contained  in  any  convexity 
- k 

constraints,  x for  k=l,. ..,N  denotes  the  structural  variables 
P P 

constituting  the  p~th  GUB  set,  a^  denotes  the  constraint  co- 
efficients for  the  i-th  equation,  and  b^  is  the  right  hand  side 
(RHS)  for  constraint  i.  Equation  [1]  represents  the  intercon- 
necting constraints  and  Equation  [2]  represents  the  GUB  convexity 
constraints . 
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This  special  structure  arises  naturally  in  many  problems, 
for  example,  transportation,  distribution,  and  multi— item 
scheduling.  GUB  structure  also  results  when  the.  Dantzig-Wolf 
decmoposition  principle  is  used  to  solve  linear ’programs  whose 
constraint  matrices  have  block  angular  structures. 

GUB  can  also  be  used  to  obtain  approximate  solutions  to 
binary  multiple  choice  programs.  In  these  situations,  the  con- 
vexity constraints  represent  the  multiple  choice  restrictions 
for  the  binary  decision  variables.  This  means  that  the  convexity 
constraint,  S x^  = 1,  combined  with  the  binary  restriction, 

= 0 or  1,  ensures  that  one  and  only  one  x'^  will  be  nonzero. 

The  resulting  binary  problem  is  then  solved  as  a continuous  LP 
using  GUB.  Clearly,  not  ail  of  the  resulting  optional  decision 
variables  will  be  binary.  Fortunately,  if  the  number  of  GUB 
rows  (P)  is  much  larger  than  the  number  of  interconnection  con- 
straints (m)  , then  most  of  the  variable  (P-m)  will  be  binary  in 
the  optimal  solution.  This  important  result  is  often  used  to 
yield  approximate  solutions  to  large  multiple— choice  decision 
problems . 

2.4.35.2  Modules  Galled 
None 

2.4.35.3  Module  Input 

P 

1)  The  total  number  of  structural  variables  - N ^ S 

i=l 

2)  The  number  of  non-GUB  constraints  - m 

3)  The  number  of  GUB  constraints  - P 

4)  The  number  of  elements  in  each  GUB  set  - n_ 
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5)  The  RHS  vector  - b (including  GUB  rows) 

6)  The  type  of  each  constraint  (equality,  inequality,  etc) 

7)  The  constraint  matrix  for  nonGUB  rows 


- 

\ l/mxn 


2.4.35.4  Module  Output 

1)  Output  option  indicator 

2)  Iteration  summary 

a)  Key  columns 

b)  Indices  df  current  basis  elements 

c)  Values  of  variables  in  current  basis 

d)  Entering  column 

e)  Simplex  multipliers 

f)  Current  cost  function  value 

3)  Solution  summary 

a)  Indices  of  variables  in  optimal  basis 

b)  Optimal  values  for  the  structural  variables 

c)  Value  of  each  run  GUB  row  in  constraint  matrix 

d)  Cost  function 

e)  Simplex  multipliers 

2.4.35.5  Functional  Description 
■» 

The  generalized  upper  bounding  procedure,  developed  by 
Dantzig  and  Van  Slyke(l) , is  a specialization  of  the  simplex 
method.  The  key  feature  of  GUB  is  that  it  solves  the  LP  defined 
in  Equations  [1]  and  [2],  while  maintaining  a "working"  basis  of 
dimension  rnxm.  Thus,  all  quantities  required  to  make  a simplex 
like  iteration  are  computed  in  terms  of  this  reduced  "working" 
basis. 
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[3] 


[4] 


GUB  can  be  motivated  by  considering  the  following  facts: 

1)  Any  feasible  bases  for  Equation  [1]  ~ [2]  must  contain  at 
least  one  element  from  each  GUB  set. 

2)  An  elementary  matrix  transformation  that  transforms  the  basis 
into  upper  block  triangular  form  can  be  defined,  hence, 
enabling  a basis-feasible  solution  to  be  computed  in  terms 
of  a mxm  submatrix. 

Clearly,  in  order  to  satisfy  each  GUB  convexity  constraint, 

E x'^  --  1,  at  least  one  of  the  variables  must  take  on  a nonzero 
value.  This  implies  that  any  feasible  basis  must  contain  at 
least  one  column  from  each  GUB  set.  Suppose  we  select  one  such 
column  from  each  GUB  set  and  enter  these  columns  as  the  first  p 
columns  iir  the  basis . The  remaining  m columns  are  then  selected 
from  the  nonkey  columns.  The  basis  can  then  be  partitioned  as 
follows : 


B = 


mxp 


pxp 


mxm 


pxm 


_|  m+p  X m-t-p 
key  columns  nonkey  columns 

The  important  property  of  B is  that  the  submatrix  is  composed 

binary  elements,  which  enables  on  elementary  matrix  to  be  con- 


structed as  follows: 

I 


BE  = 


mxp 


pxp 


B 


mxm 


pxm 
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is  upper  block  triangular.  The  elementary  transformation  E is 
easily  constructed  by  subtracting  the  appropriate  columns  of 


from 


B 

C 


The  elementary  matrix  that  performs  these  simple  column  opera- 
tions is  given  by 


I ' -C 
pxp  I pxm 


mxp  I mxm 


Now  suppose  that  we  have  a basic  feasible  solution 

[6]  Xg=B-lb, 
and  define 

[7]  y^  = E"lx„  = B“^  b = (BE)"^b. 

Clearly,  y is  then  a basic  feasible  solution  of  the  transformed 
^ B 

system 

[8]  (BE)  y^  •=  b. 

The  solution  of  the  transformed  system 


A 

mxp 

B 

mxm 

>'p 

— — 

h 

m 

I 

pxp 

0 

1 pxm 

m 

1 

P 

is  easily  calculated  from  the  reduced  problem 


[10] 


By  =b-Ay 
mxm  m m • mxp  p 

y = 1 . 

P P 

It  is  evident  from  Equation  [10]  that  the  determination  of  a 

basic  feasible  solution  is,  in  essence,  equivalent  to  solvin  5 fo*. 

V . The  calculation  of  v requires  only  the  inverse  of  the 
■'m  ■ - m.  , 

"working”  mxm  basis , B”^  . This  fact  motivates  the  principax 
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[11] 

[12] 


[13] 


advantage  of  the  GUB  algorithm,  and  enables  each  operatxon  re- 
quired in  applying  the  simplex  method  to  Equation  [1]  - [2]  to 
be  performed  in  terms  of  the  quantities  associarad  with  the 

reduced  basis, 

The  outline  of  key  modifications  to  the  simplex  operations 
required  by  GUB  follow.  These  equations  are  derived  xn  Reference 


1,  and  are  based  on  the  working'  basis  inverse. 

Calculating  the  Simplex  Multipliers  - Let  (tt,  y)  be  the 
simplex  multipliers  for  the  basis  B,  where  tt  is  a m-component 
row  vector  associated  with  the  first  m equations  and  y is  a p 
component  row  vector  associated  with  the  last  p equations. 
These  multipliers  are  calculated  as 


(tt 


1 » ’'2» 


n ) = (0,0,  . . . , 0,1)B- 
m 


(B 


m 


where  denotes  the  index  of  the  i-th  key  column. 

Calculating  the  Relative  Cost  Coefficients  - This  is  done  in 

the  usual  way 

c.  = - y , if  a . e J , 

3 X j k J K- 

wherej’  , denotes  the  k-th  GUB  set. 

K- 

Representing  the  Entering  Colwnn  in  Terms  of  the  Current 
Basis  - The  column  that  enters  the  basis  is  selected  in  the 
standard  manner  by  computing  = min  c^  over  all  nonbasxc 
columns.  If  >_0,  the  current  solution  is  optimal.  If 
c •'  0 then  A enters  the  basis.  For  the  purpose  of  discussion, 

s ’ s 

let  A t . NoX'J  to  see  vdiich  column  leaves  the  basis,  the 

s 0 

transformed  column 
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[14] 


[15] 

[16] 

[17] 

[18] 

[19] 


[20] 


[21] 


A = A 
s s 

must  be  computed.  GUB  structure  enables  the  transformed  columns 
to  be  calculated  from  the  reduced  "working"  basis ^ The  equations 
that  perform  this  transformation  are: 

- E for  l<i<p,  i?^o 

keT.  ® 

,-X  _ 7 X 

1 - E d"^,  for  i ^ a 
keF.  ® 

X 

A^'*'^  = , for  k = l,2,..,,m, 

s s 

where 

D = B-^/A  - A 


= |k  : k {l,2,...,m}  and  r^^  = i| 


and 

r,  = i,  for  k = l,2,...,m, 

k 

if  the  p+k-th  column  of  B is  an  element  of  the  i-th  GUB  set, 
that  is,  . 

Vk  ^ {^11’  ^2i”-*’Vi}  * 

Choosiyig  ~th&  Colwnyi  to  L&clV&  the  Basts  - This  is  done  in  the 
usual  way,  by  computing 
B 


6 = X 


y^r  ^ "‘j''  I''  - °| 


if  all  A >0,  the  solution  is  unbounded, 
s 
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Updating  the  Basic  Variables  - The  basic  variables  are  updated 

according  to  the  formula 
B.  B. 

[22]  X ^ ^ X ^ for  i = l,2,...,m+p,  i ^ r 

B. 

X 9 , for  i = r • 

Updating  the  Inverse  of  the  Working  Basis  - Let  ^ bo 

the  column  entering  and  A.  be  the  column  leaving.  There 

J P o 

are  two  cases  to  be  considered. 

Case  1.  A.  is  not  a key  column.  In  this  case,  A.  is 

J i ' 

-^r  -^r 

replaced  in  B by  A^  in  one  of  the  last  m columns,  The  only  re- 
sulting change  in  the  working  basis  is  that  the  column  of  B 
corresponding  to  the  leaving  column  is  replaced  by  ^A  “A. 


is  updated  by  adjoining  the  column 


[23] 


D = B 
s 


-1 


(*■  - \) 


and  performing  a pivot. 

Case  2.  A.  is  a key  column. 

^r 

1)  A.  and  A are  from  different  CUB  sets  (i.e.,  a p)  . Select 
ns  , - 

r 

one  nonkey  column  in  J and  interchange  it  with  A.  . The 
situation  then  becomes  that  of  Case  1.  Clearly,  such  a 
nonkey  column  must  exist  in  order  for  A.  to  be  selected 

^r  P 

for  removal. 


2)  A.  and  A are  from  the  same  GUB  set  li.e.,  a = p) 
j s . j 

Jr 

a)  if  there  exists  at  least  one  nonkey  column  that  3.s  a 
member  of  j , 

^ select  one  and  interchange  it  with 

A.  , and  apply  the  operations  described  in  Case  1. 

Jr 
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b)  If  no  nonkey  colunm  is  from  ^ ^ then  replaces  . 
However,  since  the  last  m columns  of  B do  not  contain 
elements  of  J the  working  basis  does  not  change.  The 
upper  left  partition  of  B does,  however,  change  when 
replaces  A^  . 
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2.4.35.6  Functional  Block  Diagram 
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OBIGINAi;  PAGE  IS 
OP  POOR  ODALiry 
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2 . 4 • 35  . 7 Typical  Applications 


As  mentioned  earlier,  GUB  structure  arises  naturally  in  many 
scheduling  problem  formulations.  For  example,  the  PWW  project 
scheduling  formulation,  the  simplified  activity  scheduling  formu- 
lation, multi-item  scheduling,  and  resource  allocation  problems 
all  contain  GUB  structure.  This  does  not  mean,  hoxvever,  that 
GUB  is  the  best  aJgorithm  for  all  of  these  formulations.  Other 
fundamental  considerations  (such  as,  integrality)  and  numerous 
problem-dependent  factors  (such  as,  the  ratio  of  P to  m)  determine 
which  algorithm  should  be  used.  However,  independent  of  any  of 
these  other  considerations,  a GUB  structured  LP  can  be  very 
efficiently  solved  with  this  type  module. 

2.4.35.8  Implementation  Considerations 

The  advantage  of  GUB  is  that  it  efficiently  solves  a special 
class  of  LP  problems.  However,  this  tool  must  be  used  on  rela- 
tively large  problems  (m  ^ 100,  p ^ 100,  n ^ 1000)  before  the 
computational  savings  are  of  any  real  consequence.  On  small 
problems,  the  difference  between  GUB  and  revised  simplex  is 
measured  in  fractions  of  seconds  and  would,  in  our  opinion,  not 
justify  the  GUB  development  costs. 

For  the  solution  of  extremely  larger  GUB  problems  (m  > 1000, 
p 1000,  n ^ 10,000) , a production  code  similar  to  that  contained 
in  MPSX  is  recommended.  For  mos t ‘ problems  a less  sophisticated 
GUB  algorithm,  like  the  one  specified  here,  would  be  adequate. 

The  effort  required  to  develop  the  level  of  a GUB  algorithm  i^ould 
be  slightly  higher  than  that  of  a versatile  primal  simplex  code. 
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This  11163.113  th3t  it  wouid  t3k.6  bssicsliy  two  to  thr66  Tn3n~inonths 
of  developinsrit  to  coniplEtely  fomiulste,  codB,  chockout,  snd 
document  this  module. 
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2.4.36  MIXED_INTEGER_PROGRAM 

2.4.36.1  Purpose  and  Scope 

This  module  can  be  used  to  optimize  any  system  whose  perfor- 
mance can  be  mathematically  modeled  as  a linear  function  in  a set 
of  decision  variables  that  are  subject  to  both  linear  algebraic 
and  integrality  constraints.  Symbolically,  the  problem  of  de- 
termining the  optimal  system  configuration  must  reduce  to  a 
mathematical  problem  of  the  form 
Minimize:  z = C2X  C^Y 

Subject  to;  A2X  + A^Y  b 
X integer 

where : 

X is  an  nxl  integer  column  vector  of  unknowns, 

Y is  a pxl  continuous  column  vector  of  unknowns, 

C is  a Ixn.  continuous  row  vector  of  cost  coefficients  for  the 
integer  variables , 

e is  a Ixp  continuous  row  vector  of  cost  coefficients  for  the 
continuous  variables , 

A is  an  mxn  continuous  matrix  of  constraint  coefficients  for  the 
binary  variables , 

D is  an  mxp  continuous  matrix  of  constraint  coefficients  for  the 
continuous  variables , 

b is  an  mxl  continuous  column  vector  of  constraint  limits. 
2.4.36.2  Modules  Called 

This  module  requires  a special  purpose  Geoff rion  code  that 
solves  a mixed  integer  program  containing  a single  continuous 
’^^ariahle . 
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2.4.36.3  Module  Input 


1)  The  objective  function  coefficients  c and  e. 

2)  The  constraint  matrices  A and  D 
e)  The  RHS  vector  b . 

2.4.36.4  Module  Output 

1)  Value  of  the  decision  variables 

2)  Final  objective  function  Value 

3)  Iteration  Summary 

2.4.36.5  Functional  Description 

Branch  and  bound  type  algorithms  have  classically  been 
applied  to  mixed-integer  programs.  Unfortunately,  B&B  methods 
can  be  inefficient  if  the  number  of  integer  variables  is  large. 

This  is  because  of  the  branching  rule  that  merely  dichotomizes 
the  continuous  solution  for  each  integer  variable. 

For  problems  of  practical  size,  this  procedure  produces  so 
many  LP  subproblems  that  even  very  fast  simplex  codes  do  not  make 
this  approach  feasible . For  problems  with  only  a few  integer 
variables,  B&B  methods  ai'e  adequate  and  are,  in  fact,  recommended. 

When  the  number  of  integer  variables  is  large,  the  Bender 
decomposition  algorithm  is  the  most  effecient.  Heuristically , 
this  statement  can  be  motivated  by  the  observation  that  Bender's 
algorithm  exploits  the  integer  properties  of  the  problem,  which 
in  this  case  dominate  the  solution  process.  As  a consequence, 
Bender’s  method  requires  a fast  0-1  code  in  contrast  to  the  B&B 
methods  v^^hich  require  a fast  LP  code.  Fortunately,  several  fast 
0-1  codes  exist,  e.g.,  Geoffrion's  extension  of  the  Balas  algorithm. 
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Bender’s  algorithm  makes  use  of  the  fact  that  for  given  values 
of  X,  the  problem  reduces  to  an  LP  whose  dual  is  independent  of 
any  particular  choice  of  x.  This  enables  an  equivalent  program 
with  only  one  continuous  variable  to  be  formulated  that  can  be 
solved  as  a subproblem  to  yield  the  overall  integer  solution.  A 
brief  description  of  this  approach  follows. 

2.4.36.6  Fiinctlonal  Block  Diagram 


2.4.36-3 


Rev  A 


^Yes 

Solve  the  LP 
min  : ey 
Subject  to 
Dy  ^ b - Ax 

y 1 0 

for  the  optimum  value 
of  the  continuous 
variables  y. 
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Rev  A 


2.4.36.7  Typical  Applications 


This  module  can  be  applied  to  a wide  variety  of  small  OR  type 
problems,  e.g. , capital  budgetary,  project  selection,  and  al- 
ternative resource  allocation.  The  modeling  is,  of  course,  re-, 
stricted  by  the  structure  of  the  resulting  mathematical  program. 

2.4.36.8  Implementation  Considerations 

Since  this  module  has  already  been  implemented,  the  numerous 
implementation  considerations  are  described  in  the  program 
documentation . 

2.4.36.9  Reference 

Benders,  J.  F.:  "Partitioning  Procedures  for  Solving  Mixed- 

Variable  Programming  Problems,  Numerische  Mathematika,"  Vol  4, 
1962 . 
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2.4.37  PRIMAL__SIMPLEX 

2.4.37.1  Purpose  and  Scope 

Primal  simplex  is  an.  iterative  algorithm  for  solving  the 

general  class  of  problems  referred  to  as  linear  programming. 

Briefly  stated  a linear  program  (LP)  is:  given  a set  of  m linear 

inequalities  or  equations  in  n variables,  determine  the  nonnegative 

values  of  these  variables  that  satisfy  the  constraints  and 

optimize  some  linear  function  of  the  variables.  Mathematically 

stated;  determine  the  values  x'^ , j = l,2,...,n  that  minimize; 

n . 

[1]  z = X c.x^ 
j=l  ^ 

Subject  to : 

X x^  - b^  ^ 0 i = l,...,m 

j ^ 

x^  ^ 0 

The  capability  to  solve  the  LP  defined  by  Equation  [1]  is  funda- 
mental to  any  mathematical  programming  system.  As  a consequence, 
a large  number  of  high  performance  codes  exist  for  solving  this 
basic  class  of  problems  (Ref  5,  6,  7).  The  principal  components 
common  to  all  of  these  operational  codes  are  a modification 
of  the  basic  revised  simplex  method  by  using  the  product 
form  of  the  inverse,  multiple  pricing,  and  a composite  approach 
for  phase  I . The  reason  that  so  much  emphasis  has  been  placed 

t 

on  speed  and  efficiency  of  the  primal  algorithm  is  that  it  is 
used  repetitively  by  many  other  algorithms.  For  example,  mixed 
integer  and  nonlinear  separable  programs  both  require  an  extremely 
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fast  primal  algorithm  to  solve  the  numerous  LP  subproblems  (typ- 
ically several  hundred)  that  arise  in  the  solution  of  the  master 
programs . 

Current  operational  systems,  such  as  those  described  in 
References  6,  7,  and  8,  are  capable  of  solving  problems  with 
10  000  constraints  and  essential  unlimited  number  of  decision 
variables.  Problems  with  1000  constraints  are  considered  to  be 
medium  sized.  The  solution  of  problems  of  this  size  requires 
that  the  programming  of  the  algorithm  be  done  in  assembly 
language  to  allow  maximum  computational  efficiency . For  problems 
of  this  magnitude,  efficiency  is  synonymous  with  feasibility. 

2.4.37.2  Modules  Called 

None 

2.4.37.3  Module  Input 

The  cost  effective  solution  of  large  LP  problems  requires 
extensive  data  handling  capabilities . These  capabilities  are 
needed  to  give  the  user  flexibility  and  freedom  in  storing  and 
operating  upon  the  large  masses  of  problem  input  data.  In  fact, 
the  majority  of  the  routines  in  any  standard  mathematical  pro- 
gramming system  are  related  to  the  data  handling  efforts . 

The  essential  portions  of  the  LP  input  are  the  large  problems 
these  data  are  seldom  input  directly  by  the  user,  but  rather 
generated  or  obtained  from  data  previously  written  on  mass 
storage  devices.  In  any  event,  the  data  required  are  always 
essentially  the  same: 
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1)  The  objective  function  coefficients,  c^ , j = 

2)  The  constraint  matrix,  a^,  i = j = l,...,n. 

3)  The  RHS  vector,  b^,  i = 1 m. 

4)  The  constraint  specification  type,  (=,  > 

2.4.37.4  Module  Output 

The  primal  simplex  routine  is  not  only  capable  of  solving 
the  LP,  but  it  can  also  provide  auxiliary  information  that  is 
often  as  useful  as  the  answer  itself.  Apart  from  a complete 
report  writing  capability,  which  is  in  itself  a major  issue,  the 
minimum  output  of  the  primal  simplex  code  should  consist  of: 

1)  Summary  of  certain  key  input  information  (costs,  bounds, 
etc) ; 

2)  Status  cf  each  variable  in  the  final  solution,  i.e.,  basic 
or  nonbasic,  feasible  or  nonfeasible,  bounded  or  slack,  etc; 

3)  Value  of  each  basic  variable; 

4)  Final  objective  function  value ; 

5)  Shadow  prices  (Lagrange  or  simplex  multipliers) ; 

6)  Iteration  history  summary,  i.e.,  iteration  counter,  indices 
of  basic  variables,  objective  function  value,  etc. 

In  some  cases  the  algorithm  may  fail  to  converge  and  a diagnostic 
printout  is  required.  The  required  printout  is  somewhat  problem 
dependent;  however,  at  a minimum  it  should  include  the  (1) 
relative  cost  coefficients,  (2)  basic  inverse,  and  (3)  indices 
of  the  entering  and  leaving  columns . 
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2.4.37.5  Functional  Description 

A description  of  the  primal  algorithm  can  be  found  in  numerous 
references,  and  hence,  it  is  not  presented  in  detail  here.  For 
reference  purposes,  the  code  described  in  Orchard-Hays  (Ref  2)  is 
one  of  the  most  efficient.  Reference  2 also  gives  a wealth  of 
implementation  techniques  that  should  be  reviewed  befoi-e  implemen- 
tation. Since  implementation  of  an  efficient  primal  code  is  not 
straightforward,  a general  functional  block  diagram  is  presented. 
It  is  recognized,  however,  that  many  strategy  variations  exist  in 
primal  codes.  Thus,  this  functional  block  diagram  should  only 
serve  as  a guideline  during  the  development  process. 
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2.4.37.6  Functional  Block  Diagram 


Enter 


Add  logical  variables 
and  perform  problem 
scaling. 


Obtain  starting  tableau 
by: 

1)  All  artificial 

2)  CRASH-ing 

3)  Previous  problem 
structure. 


Calculate  Inverse 
of  current  basis. 


Calculate  the  current 
values  of  the  basic 
variables . 


Calculate  the  pricing 
vector  for  Phase  I or 
Phase  II  as  appropriate. 


solution  optimal 
or  is  number  of 
iterations 
exceeded 
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2,4.37.7  Typical  Applications 


In  general,  there  are  few  scheduling  problems  that  can  be 
modeled  directly  as  linear  programs . However,  as  mentioned 
previously,  there  are  many  situations  in  which  this  module  is 
required  as  a basic  computational  routine  in  other  algorxthms 
that  do  apply  directly  to  scheduling.  In  addition  to  these 
support  functions,  this  module  can  be  used  directly  to  solve 
several  categories  of  advanced  planning  and  resource  allocation 
problems.  Simplified  problems  in  transportation  and  distribution, 
production  and  inventory,  and  macro  economics,  can  be  modeled  and 
solved  with  this  type  of  a tool. 

2.4.37.8  Implementation  Considerations 

The  most  important  observation  that  can  be  made  in  this  sec- 
tion is  that  the  development  of  an  efficient  primal  code  is 
totally  a problem  of  implementation  not  theory.  As  a result, 
every  possible  effort  should  be  made  to  ensure  that  this  algorithm 
. is  computationally  efficient.  This  can  be  accomplished  by  care- 
ful development  of  the  four  principal  areas  that  impact  the 
efficiency  of  this  module:  (1)  starting  solution,  (2)  inversion, 

(3)  pricing,  and  (4)  pivot  selection.  All  of  these  critical 
topics  have  been  thoroughly  discussed  in  the  literature.  A 
brief  summary  of  the  conclusions  regarding  these  areas  is  pre- 
sented in  Table  2.4.37.8-1.  Before  the  implementation  of  this 
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module,  it  is  recommended  that  the  references  presented  in 
Table  2,4.37  -1  be  completely  reviewed. 


Table  2,4.37-1  Summary  of  Implementation  Reciomnendation 


Category 

Principal  Recommendation 

Key 

References 

Starting 
Solution 
(Phase  I) 

- Avoid  starting  from  all  artificial 
bases . 

- Use  problem  structure  wherever 
possible . 

- CRASHing  can  have  significant  impact 
on  the  solvability  of  a particular  LP . 

2,3 

Inversion 

- Necessary  to  maintain  control  over 
numerical  round-off  problems 

- Reduces  the  size  of  the  expanding 
representation  of  the  basic  inverse. 

- Reduces  the  total  number  of  elementary 
operations  by  minimizing  the  number  of 
nonzero  elements  in  the  representation 
of  the  inverse 

8,9 

Pricing 

and 

Pivoting 

- Multiple  pricing  should  be  used. 

- Weighting  the  relative  cost  coef- 
ficients before  selection  has  often 
significantly  reduced  the  number  of 
iterations. 

- The  standard  pivot  selection  rule 
used  in  single  pricing  algorithms 
appears  to  be  best  even  in  the 
multiple  pricing  environment. 

10,11 
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2.4.38  DUAL  SIMPLEX 


2.4.38  DUAL  SIMPLEX 


. [1] 


[2] 


2.4.38.1  Purpose  and  Scope 

The.  dual  simplex  algorithm  is  a special  purpose  routine  de- 
signed to  solve  the  dual  (of  the  primal)  problem  using  the  standard 
primal  tableau.  In  essence,  it  is  the  primal  simplex  algorithm 
applied  to  the  dual  of  the  primal  problem,  where  the  dual  of  the 


LP 

Minimize  c’x 
Subject  to 

Ax  b 
X > 0 


1 


Maximize 

Subject 


TT’b 

to 


A 'll  c 
-7T  < 0 


Primal 


Dual 


The  dual  simplex  algorithm  can  be  derived  in  a straightforward 


fashion  by  applying  the  primal  simplex  rules  to  the  dual  problem. 

The  most  elementary  application  of  the  dual  algorithm  is  when 
the  number  of  rows  in  the  primal  is  much  larger  than  the  number 
of  columns . In  this  situation  the  primal  algorithm  would  have 
to  maintain  an  m-dimensional  basis  inverse  while  the.  dual  algo- 
rithm would  require  only  an  n-dimensional  basis.  The  resulting 
reduction  in  storage  and  computations  can  be  significant.  The 
dual  algorithm  is  useful  if ; 

1)  Additional  constraint  rows  are  to  be  added  to  an  LP  whose 
optimal  solution  is  known; 

2)  The  PHS  vector  b^  is  to  be  changed. 

2.4.38-1 


The  advantages  of  the  dual  simplex  in  the  above  situations  is 
that  a new  optimal,  basic  feasible  solution  can  be  easily  con- 
structed from  the  augmented  dual  problem.  This  is  because  the 
addition  of  a constraint  or  the  alteration  of  the  RHS  vector  in 
the  primal  simplex  does  not  change  the  dual  variable  constraints. 
Hence,  the  dual  solution  corresponding  to  the  optimal  primal  is 
also  a basic  feasible  solution  for  the  augmented  dual  simplex. 

The  dual  algorithm  can  also  be  used  in  certain  situations 
to  eliminate  the  need  of  a Phase  1 in  the  primal  algorithm. 
However,  it  is  often  difficult  to  find  a basic  feasible  solution 
to  the  dual  algorithm  (i.e.,  a basic  feasible  solution  to  the 
primal  with  all  positive  relative  cost  coefficients) . In  the 
worst  case,  artifical  variables  may  have  to  be  added  to  the  dual 
algorithm.  This  would  require  a Phase  1 in  the  dual  algorithm 
that  could  be  considerably  more  time-consuming  than  the  direct 
application  of  the  two-phase  method  to  the  primal  algorithm.  As 
a consequence,  utilization  of  the  dual  simplex  algorithm  is  only 
recommended  in  those  situations  where  a dual  basic  feasible 
solution  is  readily  obtained  from  the  inherent  problem  structure 

2.4.38.2  Modules  Called 
None 

2.4.38.3  Module  Input 

1)  The  number  of  structural  variables,  n 

2)  The  number  of  constraints,  m 

3)  The  primal  cost  coefficients,  c^ ; j - l,2,...,n 

4)  The  RHS  vector,  b^;  i = 1,2,. ..,m 

5)  The  constraint  matrix,  a^;  j = l,2,...,n;  i - 1,2,.. .,m 
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2.4.38.4  Module  Output: 


1)  Output  option  indicator 

2)  Iteration  Summary 

3)  Solution  Summary 

2.4.38.5  Functional  Description 

The  dual  simplex  algorithm  can  be  motivated  by  the  concept 
of  complementary  slackness.  In' essence,  complementary  slackness 
implies  that  if  the  relative  cost  coefficients  of  the  primal 
algorithm  are  nonnegative,'  then  the  corresponding  dual  variables 
are  dual  feasible.  In  general,  not  every  basic  solution  with 
H > 0 will  be  feasible.  However,  when  such  solutions  are 

j " 

feasible,  then  they  are  also  optimal.  Suppose  we  had  a basic, 
but  infeasible,  solution  that  had  all  ^ 0 and  this  solution 
was  updated  by  changing  one  column  (row  in  the  primal)  at  a 
time  while  maintaining  c^  ^ 0 for  each  update.  An  optimal,  if 
one  existed,  could  surely  be  found  in  this  manner.  This  is 
precisely  what  the  dual  simplex  algorithm  does.  However,  the 
various  simplex  rules  are  slightly  different.  For  example,  the 
dual  simplex  algorithm  computes  the  vector  to  leave  the  basis 
and  then  the  vector  to  enter.  This  is  the  reverse  of  primal 
simplex.  A summary  of  the  key  dual  simplex  operations  follows . 
These  operations  can  be  motivated  by  studying  the  structure  of 
the  dual  of  the  primal  in  canonical  form 
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[3] 


Applying  the  simplex  rules  to  this  canonical  form  yields  the  dual 
simplex  algorithm. 

1)  Calculate  the  pivot  column  (pivot  row  xn  the  primal  tableau) 


3)  Pivot  on  a 

jT  s 

4)  If  b.  ^ 0,  for  all  i = 1,2, .. . ,m, 

stop,  the  current  solution  is  optimal;  otherwise  go  to  step  1. 
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2.4.38.6  Ftmctlonal  Block  Diagram 


Enter 


Perform  problem  setup: 

1)  addition  of  logicals 

2)  scale  and  translate 
equations  . 


Compute  initial  tableau 


/ I.  \ 

'Maximum  numb.ei 
sof  iterations^ 
exc  eed  ed/^ 


Return 


Determine  row  to 
leave  the  basis  ; 


Update  the  basis 
inverse  by  perform- 
ing a pivot  opera- 
tion 


Compute  canonical  form 
solution  to  leave  the 

optimal  / 

9 ^ r 


Is  \ 
solution 
unbounded 


Compute  index  of  row 
to  enter  the  basis 


Return 
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2.4.38.7  Typical  Applications 


Dual  simplex  is  generally  used  as  a submodule  in  other 


algorithms  where  the  highly  specialized  advantages  of  the  dual 
structure  can  be  exploited.  For  example,  dual  simplex  xs  used 
internally  in  the  Benders'  decomposition  algorithm  to  solve  for 
the  extreme  points  and  rays  of  the  primal  problem  for  a fixed 
value  of.  the  integer  variables.  The  dual  is  used  in  this 
situation  because  then  the  constiaint  set  is  independent  of  any 
particular  choice  of  the  integer  variables.  (For  more  details, 
see  the  description  of  the  Bender  decomposition  algorithm.)  Dual 
simplex  is  also  used  in  the  Geofferion  zero-one  algorithm  to 
solve  for  the  strongest  surrogate  constraint.  In  both  of  these 
examples,  dual  simplex  was  used  because  in  the  process  of  solving 
the  master  program  a subproblem  was  created  that  was  particularly 
compatible  with  the  dual  algorithm.  This  is  very  typical  of  the 
situations  in  which  the  dual  simplex  module  would  be  used. 
2.4.38.8  Implementation  Considerations 

A more  general  dual  algorithm  oould  be  developed,  similar  to 
that  described  in  Ref  3 which  handles  type  1 variables  directly. 


In  this  more  general  setting,  the  dual  algorithm  is  not  the  same 
as  the  primal  simplex  applied  to  the  dual  problem. 
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2.4.39  INTEGER_PROGRAM 

2.4.39.1  Purpose  and  Scope 

This  module  can  be  used  to  optimize  any  system  whose  per- 
formance can  be  mathematically  modeled  as  a linear  function  in 
'a  set  of  bounded  integral  decision  variables  that  are  subject 
to  linear  algebraic  constraints.  The  difference  between  the 
integer  and  mixed-integer  programs  is  that  in  the  former  all  of 
the  variables  are  constrained  to  be  integral,  while  in  the  latter 
some  may  be  continuous.  Symbolically,  the  problem  of  determining 
the  optimal  system  configuration  must  reduce  to  the  following 
mathematical  program 
Minimize:  z = cx 

Subject  to:  Ax  + b ^ 0 

X integer 

where 

X is  an  nxl  integer  column  vector  of  unknowns, 

c is  a Ixn  continuous  nonnegative  row  vector  of  cost  coefficients 
for  the  integer  variables, 

A is  an  mxn  continuous  matrix  of  constraint  coefficients  for  the 
integer  variables , 

b is  an  mxl  continuous  column  vector  of  constraint  limits. 

The  implemented  FORTR/iN  codes  ZOSCA  efficifently  solves  this 
program  subject  to  certain  restrictions.  First,  the  decision 
vector  X must  be  binary  valued;  that  is,  each  of  its  components 
must  be  either  zero  or  one.  Theoretically,  this  requirement  is 
not  a restriction.  As  long  as  each  integer  decision  variables 
is  bounded  above  and  below,  it  can  be  represented  by  a set  of 
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[1] 


[2] 


[3] 


binary  variables . Suppose 

where  and  x^  are  integers.  Define  k to  be  the  unique 


smallest  nonnegative  integer  such  that 


- x^  < 


k+l_ 

Then  the  substitution 


= x^  + L 2^^ 

" i=0 

replaces  the  single  integer  variable  x^  with  the  k+1  bxnary 
variables  y^^.  In  practice,  however,  such  changes  of  varxables 
can  soon  increase  the  dimensionality  of  a problem  to  the  point 
where  it  is  no  longer  tractable  with  existing  computer  codes. 

The  second  restriction  is  that  the  number  of  constraxnts,  m,  not 
exceed  50.  The  third  and  final  restriction  is  that  the  number 
of  decision  variables,  n,  not  exceed  90. 

2.4.39.2  Modules  Called 
None 

2.4.39.3  Module  Input 

1)  The  objective  function  coefficients,  c 

2)  The  constraint  matrix,  A 

3)  The  constraint  limits,  b 

4)  Module  control  flags 

2.4.39.4  Module  Output 

1)  Final  value  of  the  decision  variables 

2)  Final  value  of  the  objective  function 
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3)  Final  value  of  the  constraint  feasibility 

4)  Optional  levels  of  iteration  diagnostics  and  decision  histories. 
2.4.39.5  Functional  Description 

The  Geoffrion  implicit  enumeration  algorithm  incorporates 

two  significant  computational  improvements  to  the  standard  Balas 

algorithm.  These  improvements  are:  (1)  a flexible  and  economical 

version  of  the  "back-track"  procedure  for  exhaustive  search  in 

combinatorial  problems;  (2)  augmentation  of  the  "strongest" 

surrogate  constraint  to  the  infeasibility  tests.  The  latter  of 

these  improvements  is  a major  contribution  in  that  it  reduces 

the  sensitivity  of  the  solution  time  to  the  number  of  integer 

variables.  In  fact,  results  suggest  that  use  of  the  imbedded 

linear  program  to  calculate  the  "strongest"  surrogate  constraint 
* 

reduces  the  solution- time  dependence  on  the  number  of  variables 
from  an  exponential  to  a low-order  polynomial. 

A functional  description  of  the  Geoffrion  algorithm  is  presented 
in  the  functional  block  diagram  in  terms  of  the  following  nomenclature 

- set  containing  the  index  of  the  elements  in  the  partial 
solution,  e.g.,  xf  = {-5,4}  implies  that  X5  = 0 and 

X4  = 1 in  the  partial  solution; 

x^  - solution  vector  obtained  from  the  trivial  completion  of^; 
z - incumbent  cost  function; 

X - solution  associated  with  z,  i.e.,  z = z(x)  = c'x; 

s z 

y - the  constraints  evaluated  as  x ; 

- variables  not  in  qsf , which  when  elevated  to  1 might 
eliminate  infeasibility; 

z - Input  estimate  of  z. 

est 
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2.4.39.6  Functional  Block  Diagram 
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2.4.39.7  Typical  Applications 

This  module  can  be  applied  to  any  linear  binary  decision 
problem.  For  example,  project  scheduling  can  be  formulated  as 
a 0-1  program,  and  can  be  solved  with  this  algorithm.  [See 
sample  problems  for  ZOSCA  (zero-one  surrogate  constraint  algo- 
rithm) . ] Experience  in  solving  scheduling  problems  with  ZOSCA 
indicates  that  only  a small  number  of  activities  can  pe  optimally 
scheduled  in  this  manner.  The  principal  limiting  factor  in  this 
approach  is  the  total  slack  in  the  activities  to  be  scheduled. 

The  more  slack  the  harder  the  problem  becomes.  If  there  is 
little  job  slack,  this  approach  becomes  computationally  feasible 
but  with  small  expected  payoff  due  to  the  highly  constrained 
situation . 
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2.4.40  REQUIREMENT  GROUP  GENERATOR 
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2.4.40  requirement_group_generator 
2.4.40.1  Purpose  and  Scope 

Scheduling  problems  that  involve  the  allocation  of  distinguishable 
specific  items  to  jobs  may  be  solved  via  a model  decomposition  in  which 
the  individual  identities  of  resources  are  initially  relaxed  leaving  only 
resource  pools.  Project  scheduling  techniques  can  then  be  applied  to 
generate  start  .times  for  all  jobs  and  to  create  the  corresponding  resource 
profiles.  To  complete  the  solution  of  the  decomposed  problem,  specific 
allocations  must  then  be  made  that  are  compatible  with  the  timeline  out- 
put by  the  project  scheduling  algorithms.  These  allocations  must  satisfy 
the  requirements  of  specific  jobs  for  resources  with  appropriate  descrip- 
tors (e.g.  a CREWMAN  for  the  job  'LAUNCH'  might  require  descriptor 
'TRAINED'  or  a truck  for  the  job  'LOAD'  might  require  a descriptor  'EMPTY'). 

The  allocations  must  also  preserve  resource  continuity  constraints  between 
jobs.  For  example,  CHECKOUT_JPAYLOAD  and  LAUNCHJPAYLOAI)  both  require  a 
payload,  and  in  fact  this  may  be  the  same  payload.  Thus  only  one  allocation 
is  required  for  the  two  jobs.  The  problem  description  must  contain  the  in- 
formation that  the  two  jobs  are  related  through  the  requirements  for  the 
same  specific  resource,  even  though  the  identity  of  this  resource  is  not 
provided. 

The  purpose  of  this  module  is  to  identify  the  jobs  which  require 
common  resources.  Its  intended  use  is  to  bring  requirements  together  into 
a group  which  is  satisfied  by  the  selection  of  a specific  resource.  The  ; 

resource  allocations  for  these  jobs  must  be  made  on  the  basis  of  a group 
requirement  and  not  on  a job-by-job  basis.  Thus,  a resource  requirement 
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group  may  be  thought  of  as  a set  of  requirements  against  which  a single 
independent  allocation  decision  must  be  made. 

2.4.20.2  Modules  Called 

None 

2.4.40.3  Module  Input 

The  input  to  this  module  will  be  the  descriptions  of  the  resource 
relations  between  jobs,  i.e.,  $JOBSET  (see  below)  with  the  RES0URCE_ 
RELATIONS  substructure.  This  structure  allows  the  problem  formulator  to 

I 

specify  that  any  of  the  resource  items  allocated  to  its  parent  process 
or  opseq  must  be  the  same  as  those  for  any  other  process  or  opseq  in  the 
same  OPSEQ  with  the  same  value  of  the  'GROUP'  node.  As  separate 
occurrences  of  a process  are  identified  as  jobs,  the  GROUP  value  must  be 
set  with  a value  that  is  the  same  for  the  jobs  within  the  opsequence  but 
different  from  that  for  a different  occurrence  of  the  opsequence.  For 
example,  if  an  opsequence  contains  two  processes  that  require  the  same 
resource,  and  the  opsequence  is  to  be  repeated  three  times,  the  GROUP 
values  that  aPP^ar  in  $J0BSET  might  be  1 under  each  of  the  two  jobs  in  the 
first  occurrence,  8 for  each  of  the  jobs  iti  the  second  occurrence,  and  15 
for  each  of  the  jobs  in  the  third  occurrence.  Thus  the  resource  selected 
must  be  the  same  within  the  same  occurrence  of  an  opsequence  but  could  be 
different  for  different  occurences  of  that  opsequence.  The  'TYPE*  value 
specifies  the  resource  type  required  by  the  job. 
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2.4,40.3  Module  Input 

The  input  to  the  module  should  be  $J0BSET  With  the  following 
minimum  structure;  $J0BSET 

O 


O (SUBNET 
ID) 


resource_ 

relations 


1 descriptors  \ interval 


o ^ o start 

(VALUE) 

(S  initial 


Q end 
(VALUE) 


(parameter) 

(VALUE) 
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2.4.40.4 


The 


TYP] 


TY] 
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RETURN 
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2.4.40.6  Typical  Applications 

This  module  provides  a mechanism  for  explicitly  allocating  resources 
by  collecting  information  about  resource  relations  between  jobs. 


2.4.40.7  Detailed  Design 

The  RESOURCE_RELATION  node  of  each  job  of  each  subnet  of  $J0BSET  is 
searched  to  find  the  next  unique  resource  type-group  pair.  Then  all  jobs 
within  that  subnot  are  examined  to  see  if  they  belong  to  the  requirement 

I 

group  defined  by  the  resource  type-group  pair.  The  job  id  of  each  job 
belonging  to  the  requirement  group  is  recorded. 

2.4.40.8  Internal  Variable  and  Tree  Name  Definitions 

$SUBNET_ID  - A pointer,  specifying  the  particular  subnet  of 

$J0BSET  currently  working  on. 

$J0BNIIM  - A pointer,  indicating  the  job  id  which  is  being 

evaluated  for  resource  relations 

$RELATED  - A pointer,  indicating  the  node  of  the  RES0URCE__ 

RELATION  structure  currently  being  examined 
$SAVE  - A, tree  which  has  the  type  and  group  values  of  the 

resource  relation  currently  being  examined 
$EXAMINED  - A tree  containing  all  resource  relations  examined 

thus  far.  It  is  pruned  after  each  subnet  of 
$J0BSET  has  been  examined 

$TYPE  NAME  - Has  the  resource  type  name  of  the  requirement 

group  being  generated 
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^GROUP_NAME 


Contains  the  ’GROUP'  value  of  the  requirement 


$JOBID 


$REIATIONS 


$REQUIREMENT_ 


group  being  generated 

A pointer,  within  the  internal  procedure  FIND_ 
ALL_JOB__IDS  which  points  at  all  jobs  in  $JOBSET 
for  the  given  subnet 

- A pointer,  pointing  at  the  RESOURCE_RELATION 
subnodes  of  $JOBID 

GROUP  - The  resultant  tree  specifying  resource  relations 
between  jobs 


2.4.40-7 
Rev  C 


2.4.40.8  COMMENTED  CODE  , . . 

RtOUIREMENT.GROUP_SENeftATORI  PR0CEDURE($J0BSET.  *RE0UIREMEN 



rIS j?LAnoNr 

rrc::;r:rv;rR::E:rGR«^ 

' sexamineo  local? 

DO  FOR  ALL  SURNODES  OF  *f  bJeium 

““  ^oS%SkS^LrsSSfoors  *o?“r/o;M5S.RE^OURCF.BEUjnON  USING 
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1.0  BASIC  SYSTEM  DESCRIPTION 

The  Martin  Marietta  Aerospace  Translator-Writing  System  (TWS) 
is  a set  of  procedures  and  software  tools  which  provide  a powerful 
method  for  rapid  implementation  of  computer  programming  language 
translators.  Aside  from  its  speed,  the  TWS  approach  to  translator 
implementation  offers  the  even  more  important  advantages  of  great 
flexibility  and  modifiability,  and  it  helps  to  insure  that  the  re- 
sulting translator  is  rigorously  defined. 

Figure  1 illustrates  the  translator  implementation  process 
using  TWS.  Manual  steps  are  indicated  by  boxes  with  darkened  comers 
There  are  two  manual  inputs  which  are  mandatory;  the  formal  language 
definition  and  the  token  definition.  These  operations  are  defined 
in  detail  later  in  this  document.  Briefly,  the  language  definition 
is  a formal  description  of  the  mapping  from  the  source  language  to 
the  desired  object  language.  This  mapping  is  expressed  in  the  form 
of  a grammar  (syntactic  definition)  of  the  source  language  which 
contains  embedded  semantic  information  expressed  in  terms  of  the 
object  language.  The  source  language  is  thus  defined  in  terms  of 
the  object  language.  Such  a grammar,  augmented  by  semantic  infor- 
mation, will  be  referred  to  as  an  "augmented  grammar". 

The  token  definition  is  a description  of  the  basic  elements  of 
the  source  language  in  terms  of  the  characters  which  comprise  them. 
This  input  contains  definitions  of  the  formats  of  identifiers, 
numeric  constants,  etc.  The  definition  takes  the  form  of  a state 
transition  matrix.  OcCaaionally , it  may  be  necessary  to  modify 
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Figure  1.  The  Translator  Implementation  Process 


the  lexical  analyzer  (subroutine)  itself,  but  a tabular  input  is 
sufficient  for  most  stream-oriented  source  languages. 

Depending  on  the  object  language,  and  possibly  on  the  logical 
properties  of  the  translation  process  (the  source-object  mapping), 
it  may  occasionally  be  necessary  to  modify  the  output  routines. 
Separate  output  routines  are,  in  any  case,  required  for  object 
languages  with  basically  different  format  (e.g.  FORTRAN'S  card- 
image  versus  PL/I's  stream  format).  Given  that  the  output  routines 
exist  for  the  specific  object  language  selected,  modification  is 
usually  not  required. 

Finally,  if  specialized  error  messaging  is  desired  (rather  than 
a constant  error  message  for  all  error  types),  a table  of  error 
messages  must  be  prepared. 

Section  2 discusses  in  detail  the  use  of  the  augmented  grammar 
for  language  definition.  Sectiaj'’  3 discusses  the  other  (supporting) 
components  of  the  generated  translator. 
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2.0  THE  TRANSLATOR  DEFINITION  METALANGUAGE 

2.1  Basic  Description 

The  TWS  is  based  upon  the  use  of  the  "augmented  grammar"  method 
of  language  definition.  The  source  language  is- defined  by  an  ordi- 
nary grammar  which  contains  additional  information  pertaining  to  its 
meaning.  This  additional  semantic  information  is  used  to  specify 
what  elements  of  the  object  language  are  to  be  generated  to 
correspond  to  particular  source  language  elements.  The  augmented 
grammar  thus  defines  the  mapping  from  source  to  object  language. 

The  augmented  grammar  is  almost  a complete  description  of  the  en- 
tire translator. 

Let  us  consider,  first,  a simple  example  containing  only  syntactic 
information.  The  method  used  to  specify  language  syntax  will  be 
that  typically  used  in  modern  linguistics  to  describe  context-free 
languages  by  means  of  a phrase-structure  grammar.  Specifically,  a 
notation  based  on  the  Backus-Naur  Form  (Naur,  1960)  will  be  used  to 
define  the  syntax  of  a very  simple  language.  Figure  2 shows  the 
syntactic  definition  of  the  sample  language. 


sentence  :=  noun_phrase  verB^phrase  ^ 
noun.phrase  article  noun  I 

VERB.PHRASE  5=  VERB  NOUN^PHHASE  I 
article  s=  ''The"  i 

noun  !=  "BOY"  I "GIRL"  » "UOG"  | "CAT”  » 
VERB  !=  "LOVES"  I "HATES"  I "BIT"  I "SAW"  ; 


Figxire  2 A Simple  Grammar 
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This  particular  language  is  sufficiently  simple  that  its  defi- 
nition can  also  be  expressed  in  English.  By  comparing  the  foinnal 
definition  in  Figure  2 with  the  natural-language  description  follow- 
ing, the  reader  should  easily  acquire  a feeling  for  the  metalanguage 
used  in  such  formal  definitions.  The  definition  says: 

1)  A sentence  consists  of  a noun  phrase  followed  by  a verb  phrase. 

2)  A noun  phrase  consists  of  an  article  followed  by  a noun. 

3)  A verb  phrase  consists  of  a verb  followed  by  a noun  phrase. 

4)  An  article  consists  of  the  word  ‘’THE". 

5)  A noun  consists  of  the  word  "BOY",  or  the  word  "GIRL",  or  the 
word  *'DOG",  or  the  word  "CAT". 

6)  A verb  consists  of  the  word  "LOVES",  or  the  x>^ord  "HATES",  or 
the  word  "BIT"  or  the  word  "SAW" . 

Such  a grammar  can  be  viewed  in  two  ways  other  than  as  a simple 
definition.  First,  it  can  be  viewed  as  a generative  grammar.  This 
particular  grammar  is  capable  of  generating  64  sentences,  such  as, 
''the  BOY  HATES  THE  CAT",  "THE  GIRL  SAW  THE  DOG",  etc.  The  genera- 
tion of  such  sentences  is  accomplished  simply  by  starting  with  the 
goal  (in  this  case  SENTENCE)  and  substituting  its  definition  (NOUN__ 
PHRASE  VERB_PHRASE) . Definitions  are  successively  substituted  for 
each  variable  that  occurs  until  no  variables  remain.  The  resulting 
string  is  an  instance  of  the  goal  (in  this  case,  a sentence).  This 
process  can  be  viewed  as  generating  a tree  such  as  that  shown  in 
Figure  3 which  describes  the  entire  derivation  of  a sentence,  or  the 
phrase  structure  of  the  sentence. 
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SENTENCE 


ARTICLE  NOUN 

••the"  "GIRL”  ”SAtir'  "THE"'  "DOG" 

Fig.  3 A Phrase-Structure  Tree 

The  other  way  of  viewing  such  a grammar,  and  the  relevant  one 
here,  is  as  the  definition  of  a parsing  process.  Parsing  is  the  in- 
verse of  the  generative  process.  Parsing  starts  with,  in  this  case, 
a sentence  like  "THE  GIRL  SAW  THE  DOG"  and  derives  the  underlying 
structure.  Figure  3 can,  therefore,  be  regarded  as  a parse  tree, 
in  which  case  the  string  at  the  bottom  is  the  initial  information 
and,  with  the  help  of  the  grammar,  the  structure  is  derived. 

Parsing  is  the  first  step  of  the  translation  process.  Once  the 
input  string  has  been  recognized  and  its  structure  ascertained,  the 
question  of  its  meaning  (the  translation  object  language)  can  be 
addressed.  This  is  not  to  suggest  that  parsing  must  be  completed 
before  object  code  can  be  generate<|,  but  parsing  is  logically  first. 


The  augmented  grammar  translation  method  involves  placement  of 
information  about  object  code  (or  meaning)  directly  in  the  grammar. 
Viewed  as  a translation  process,  the  result  is  that  object  code  is 
generated  as  parsing  occurs.  How  this  is  accomplished  will  be  seen 
in  detail  in  succeeding  sections.  A point  to  be  noted  is  that  the 
structure  and  meaning  of  a language  defined  in  this  way  is  depen- 
dent for  its  definition  on  both  the  augmented  grammar  and  the  pars- 
ing properties  that  the  translator  is  assumed  to  have. 

Parsing  Assumptions 

As  mentioned  in  the  previous  section,  the  assumed  character- 
istics of  the  translator  are  significant  when  considering  the  mean- 
ing of  a language  definition  expressed  in  augmented  grammar  form. 
The  meaning  of  the  individual  symbols  of  the  augmented  grammar  is 
not  necessarily  sufficient  to  fully  define  the  language.  Under 
certain  circumstances,  it  is  also  necessary  to  know  the  parsing 
method  employed.  Ccnsider,  for  example,  the  following  partial 
grammar  for. a programming  language. 

STATEMtNT  5 a 

cunditional.statement 
I Ur^CONDITlONAL„SrATEMENT  » 

C0Nl3ITI0NAL.^Sr  aTEMENT  1 = 

»1F»»  CONDITION  '*THEN»'  STATEMENT 
( “tLSE”  statement  1 .EMPTY  ) I 

To  avoid  the  necessity  for  complex  definitions  of  CONDITION  and 
UNGONDITIONAL_STATEMENT , the  follovzing  additional  dummy  rules  will 
be  assumed. 


CONUlFiOU  t=  "CONUITION”  » 

UNC0NDiT10NAL_i>TATEMtNT  |=  “STATEMENT"  5 

It  can  be  seen  that  this  grammar  provides  for  nested  conditional 
statements  such  as 

IF  CONDITION  THEN  IF  CONDITION  THEN  STATEMENT  ELSE  STATEMENT. 

The  statement  is  ambiguous,  however,  because  the  grammar  is  ambiguous 
Does  the  "ELSE"-clause  go  with  the  first  or  second  "IF"?  Considered 
from  a purely  grammatical  point  of  view,  it  may  not  matter.  How- 
ever, if  the  statement  is  to  have  meaning^  the  ambiguity  must  be 
resolved  since  the  two  syntactic  structures  may  not  mean_  the  same 

thing. 

There  are  two  approaches  available  for  the  resolution  of  such 
ambiguities.  The  first,  and  undoubtedly  the  most  aesthetically 
pleasing,  is  to  rewrite  the  grammar  in  unambiguous  form.  The 
grammar  for  conditional  statements  can,  in  fact,  be  rewritten  &o 
that  any  "ELSE" -clause  will  be  associated  with  the  innermost  "IF" 
that  doesn't  yet  have  an  "ELSE" -clause.  Unfortunately,  the  result- 
ing grammar  is  considerably  more  cumbersome  than  that  just  presented 
It  is  unambiguous,  however,  and  that  is  an  absolute  requirement. 

The  second  approach  is  the  one  adopted  here,  both  to  keep  the 
grammar  simple  and  to  allow  some  more  powerful  specification  "tricks 
This  approach  is  to  assume  a particular  parsing  method.  Specific- 
ally, top-down  deterministic  parsing  has  been  assumed.  This 
assumption  allows  otherwise  ambiguous  grammars  (such  as  that  just 
presented  for  conditional  statements)  to  be  unambiguous. 


A brief  natural-English  description  of  the  parsing  process  for 
a single  statement  will  be  given.  Unfortunately,  space  does  not 
allow  a detailed  discussion  of  parsing  methods  in  this  document. 

Readers  desiring  further  information  should  consult  a standard 
reference,  such  as  Aho  & Ullman  (1972)  or  Cries  (1971).  The  basic 
properties  of  top-down  deterministic  parsing  are;  (1)  once  the 
first  syntactic  element  in  an  expression  has  been  recognized  in  the 
input  string,  the  parser  is  committed  to  that  expression  and  will 
not  consider  any  alternative;  (2)  alternatives  are  considered  in 
order;  (3)  if  the  first  syntactic  element  of  an  alternative  is  not 
found,  the  next  alternati.ve  is  considered;  (4)  reiterating  point 
(1),  n£  backup  ever  occurs  once  the  first  syntactic  element  of  an 
expression  has  been  recognized. 

Let  us  consider  how  top-down  deterministic  parsing  affects  the 
parsing  of  the  statement 

IF  CONDITION  THEN  IF  CONDITION  THEN  STATEMENT  ELSE  STATEMENT 
using  the  previous  grammar  for  conditional  statements.  The  goal  is 
a STATEMENT.  Therefore,  the  input  string  is  examined  for  concord- 
dance  with  the  definition  of  STATEMENT.  The  first  alternative, 
CONDITIONAL_STATEMENT,  is  considered  and  its  first  syntactic  element, 
"IF",  is  recognized  in  the  input  string.  "CONDITION"  is  readily 
identified  as  an  instance  of  the  required  metavariable,  CONDITION, 
and  "THEN"  is  recognized.  The  next  required  element  in  the 
CONDITIONAL_STATEMENT  definition  is  a STATEMENT.  This  makes  STATE- 
MENT the  goal  again,  but  the  remainder  of  the  input  string  is  now 
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IF  CONDITION  THEN  STATEMENT  ELSE  STATEMENT. 

This  is  readily  recognized  as  another  conditional  statement  and  the 
first  three  symbols  are  processed  by  the  same  .mechanism  as  before. 

This  returns  us  again  to  STATEMENT  as  a goal,  but  with  only  STATEMENT 
ELSE  STATEMENT  remaining  in  the  input  string.  Since  the  next  symbol 
in  the  input  string  is  not  "IF",  the  CONDITIONAL_STATEMENT  alter- 
native is  rejected.  "STATEMENT"  is  recognized  as  an  UNCONDITIONAL^ 
STATEMENT  and  removed  from  the  input  string. 

Now  consider  the  current  status  of  the  parser.  It  has  just 
recognized  the  STATEMEirr  element  required  by  the  definition  of  the 
inside  CONDITIONAL__STATEMENT . It  is  still  in  the  process  of  iden- 
tifying the  STATEMENT  element  of  the  outside  CONDITIONAL_STATEMENT . 
What  does  it  look  for  next?  The  next  element  it  seeks  is  the 
symbol  "ELSE"  as  a part  of  the  inside  CONDITIONAL__STATEMENT.  Since 
the  input  string  now  looks  like 
ELSE  STATEMENT 

the  requirement  is  satisfied,  and  the  "ELSE"-clause  is  always 
associated  with  the  innermost  C0NDITIONAL_STATEMENT . Hence,  an 
ambiguous  grammar  has  been  rendered  unambiguous  in  application. 

Since  the  TWS  uses  top-doxm  deterministic  parsing,  it  is  theo- 
retically limited  to  a particular  class  of  languages  capable  of  being 
parsed  in  this  manner.  There  are,  however,  several  specific  pro- 
visions of  the  TWS  which  serve  to  increase  the  parsing  power  of  the 
system.  Furthermore,  the  relevant  class  of  languages  encompasses 
most  well-formed  programming  languages,  so  this  limitation  is  not 


serious . 


2.3  Metalanguage  Primitives 

This  section  describes  all  the  primitive  symbols  ordinarily 

t 

found  in  the  augmented  grammar  definitions  used  by  the  TWS.  These 
primitives  are  readily  separable  into  several  classes,  which  will 
be  discussed  in  the  following  order: 

2.3.1  Grammar  and  translator  structure 

2.3.2  Terminal  symbols  and  symbol  classes 

2.3.3  Internal  symbols 

2.3.4  Stack  Manipulation 

2.3.5  Output 

2.3.6  Symbol  table  operations 

2.3.7  Artificial  control 

2.3.8  Error  recovery  and  messages 

First,  a brief  description  of  the  basic  grammar  structure  is  in 
order.  Every  gratnmar  begins  with  a start  ("  ,AUG_GRAM")  statement 
and  ends  with  ".END”.  Between  these  statements,  the  grammar  contains 
one  or  more  rules.  Each  rule  consists  of  the  rule  name  (which  must 
•have  identifier  syntax)  followed  by  the  string  which  has  the 

meaning  "consists  of'.  The  body  of  the  rule  then  consists  of  one 
or  more  alternatives,  separated  by  the  or  symbol  (|).  Within  an 
alternative  there  must  appear  at  least  one  syntactic  element,  and 
there  may  appear  any  number  of  additional  syntactic  and  semantic 
elements.  Several  types  of  syntactic  elements,  as  well  as  semantic 
elements,  are  defined  later  in  this  section.  An  additional  syn- 
tactic element  not  mentioned  later  is  the  name  of  a rule.  By  writ- 
ing the  name  of  a rule  within  the  body  of  another  rule,  the  user 
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causes  the  named  nile  to  be  applied  during  the  parsing  process. 

A few  additional  conventions  require  explanation.  If  it  is 
desired  to  combine  several  alternatives,  so  that  the  satisfaction 
of  any  one  of  them  will  constitute  satisfaction  of  a syntactic 
requirement,  the  alternatives  may  be  separated  by  or  symbols  and 
grouped  in  parentheses,  as 

(ALTERNATIVE_1  | ALTEKNATIVE_2  | ALTERNATIVE'S). 

There  is  also  an  iteration  operator,  the  dollar  sign  ($),  which  is 
read  "zero  or  more  occurrences  of  . . Thus,  a list  of  items 

separated  by  commas  might  be  represented  by  the  rule 
LIST  :=  ITEM  $(","  ITEM); 

The  final  semicolon,  incidentally,  serves  to  terminate  the  rule. 

2.3,1  Grammar  and  Translator  Structure 

The  semantic  elements  listed  below  are  basic  to  the  structure  of 
both  the  augmented  grammar  and  the  resultant  generated  translator. 

• .AUG  GRAM  - This  must  be  the  first  element  in  any  augmented  grammar 
since  it  causes  initialization  of  the  generated  translator.  <.AUG_, 
GRAM  must  be  immediately  followed  by  the  name  of  the  goal  rule.  The 
goal  rule  name  may  optionally  be  followed  by  the  following  two  para- 
meters enclosed  in  parentheses; 

.INITIAL  CODE  - specifies  a dataset  that  contains  initialization 
code  (e.g.,  declarations)  to  be  included  at  the  beginning  of 
the  generated  translator, 

.FINAL__CODE  - specifies  a dataset  that  contains  wrapup  code 
(e.g.,  statistical  output  statements)  to  be  included  at  the  end 
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of  the  generated  translator.  Any  such  code  be  executed 

upon  satisfactory  completion  of  parsing  by  the  new  translator. 

The  datasets  specified  by  these  two  parameters  must  be  members  of 
a user-defined  library  file.  If  a user  wished  to  write  a .AUG_GRAM 
statement  for  a grammar  called  GRAMMAR_37  and  l^iad  the  appropriate 
initial  and  final  code  in  datasets  START_UP  and  WRAP_UP , the  state- 
ment would  look  like  this: 

. AUG_GRAM  GRAMMAR_3  7 ( . INIT IAL_CODE=START_UP , .F  INAL_GODE=WRAP_UP ) 
• .END  - this  must  be  the  last  element  in  a grammar.  It  simply  indi- 
cates that  there  are  no  more  rules  in  the  grammar, 

2.3.2  Terminal  Symbols  and  Symbol  Classes 

Two  different  mechanisms  exist  which  allow  the  TWS  user  to 
specify  that  a particular  element  must  appear  in  the  input  string 
at  a particular  point  in  the  parsing  process.  The  first  of  these 
is  concerned  with  specific  symbols,  and  was  illustrated  in  the 
sample  language  of  Figure  2,  If  it  is  desired  to  test  for  a spe- 
cific character  string,  that  string  is  enclosed  in  quotation  marks 
(”),  as  ”READ",  "WRITE",  etc. 

Frequently,  the  specific  character  string  is  irrelevant,  but  it 
is  necessary  to  test  for  the  presence  of  an  element  of  a terminal 
Symbol  class.  Several  such  classes  are  in  common  use,  and  the  TWS 
provides  for  them.  New  classes  can  be  readily  added.  The  establish' 
ment  of  a class  is  accomplished  by  providing  for  it  in  the  TWS . The 
specific  properties  which  that  class  possesses,  however,  are  deter- 
mined by  the  lexical  analyzer  and  may  be  varied  from  language  to 
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language.  A typical  set  of  these  ’'tokens*'  is  briefly  described 
below. 

.ID  - An  identifier  consists  of  a string  of  alphanumeric  and 
break  (underbar)  characters  up  to  31  in  length.  The 
first  character  must  be  alphabetic. 

.LABEL  - A label  consists  of  an  identifier  followed  immediately 
by  a colon.  (e.g.  THIS_IS_A_LABEL: ) 

,NUM  - A number  is  defined  to  be  any  of  the  conventional 

representations  for  a unsigned  fixed  or  floating  point 
value,  (e.g.  84,  5.274E-19,  61.8) 

.STRING  “ A string  is  enclosed  in  single  quotes  (?)  and  may  be  up 
to  255  characters  in  length.  Single  quotes  may  appear 
within  the  string  only  in  adjacent  pairs. 

2.3.3  Internal  Symbols 

The  TWS  provides  two  kinds  of  internal  symbol.  The  first  of 
these,  called  a "symbolic  name  for  internal  reference"  (SNIR) , 
provides  a mechanism  for  automatic  generation,  by  the  translator,  of 
dummy  variable  names,,  labels,  etc.  This  mechanism  is  used  whenever 
it  is  necessary  to  output  a name  not  contained  in  the  source  program, 
if  that  name  is  required  to  vary  with  repeated  outputs.  The 
simplest  example  is  the  generation  of  labels.  If  the  translator 
is  required  to  generate  labels,  they  must  obviously  all  be  different. 
Yet  the  grammar  which  generates  them  cannot  refer  to  all  possible 
labels;  it  must  be  able  to  cause  output  of  "the  next"  label  by 
referring  to  some  symbolic  name.  This  capability  is  provided  by  the 
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SNIR,  as  is  the  capability  to  generate  groups  of  temporary  (or 
reuseable)  names  for  use  as  dummy  variables.  A SNIR  is  referred 
to  as  a string  followed  by  an  asterisk  and  a number,  as  "LABEL*0l" . 
LABEL*01  is  a reference  to  the  first  translator -generated  label 
which  was  available  at  the  time  of  entry  into  the  current  rule. 

The  second  internal  sjnnbol  type  is  the  switch,  or  flag,  which 
can  be  set  and  tested  at  parsing  time  as  directed  by  the  augmented 
grammar.  This  capability  allows  a rule  to  be  used  for  slightly 
varying  purposes  without  rewriting  the  rule  in  multiple  copies. 

It  also  allows  memory  of  simple  information  throughout  part  or  all 
of  the  parsing  process,  and  thus  allows  the  grammar  to  behave  some- 
what like  a parametric  grammar. 

.SNIR  USE  - This  element  is  used  to  reserve  SNIR's  (symbolic  iiames 
for  internal  reference)  for  use  by  the  grammar  rule  in  which  they 
appears.  The  number  of  each  SNIR  type  to  be  reserved  is  specified 
in  a parenthesized  list  that  immediately  follows  .SNIR_USE.  For 
example,  if  a user  wished  to  reserve  one  SNIR  of  type  "LABEL"  and 
three  of  type  "NUMBER",  the  first  element  on  the  right-hand- side  of 
the  appropriate  rule  would  be;  .SNIRJISE  (IABEL*01,NUMBER*03)  . It 
is  convenient  to  think  of  each  SNIR  type  as  a list  of  actual  vari- 
able names  with  an  associated  availability  pointer.  .SNIR__USE 
reserves  a given  number  of  the  actual  variable  names  (so  that  they 
can  be  referenced  symbolically  in  the  rule)  and  also  advances  the 
availability  pointer  by  that  number.  It  is  by  this  approach  that 
.SNIR  USE  allows  nested  rules  to  generate  and  use  their  own  sym- 
bolic variables  without  mutual  interference. 


• .RESET-  This  element  is  used  to  logically  perform  the  inverse 
function  of  .SNIRJQSE  by  allowing  the  user  to  move  the  availability 
pointer  for  one  or  more  SNIR  types.  The  appropriate  symbolic  name 

is  used  to  refer  to  the  variable  to  which  the  pointer  is  to  be  moved. 
.RESET  can  be  used  to  allow  different  rules  to  access  the  same  vari- 
able and  to  make  dummy  variables  available  for  reuse. 

• .SET  - This  element  provides  a mechanism  for  the  storage  of  temporary 

state  information  by  the  generated  translator  during  the  parsing 
process.  It  allows  the  use  of  status  switches  so  that  similar  rules 
can  be  combined  to  avoid  redundancy.  The  variable  and  the  value  it 
is  to  be  set  to  are  specified  in  a typical  assignment  statement  for- 
mat enclosed  in  parentheses  immediately  following  .SET.  For  example, 
if  a user  wants  to  set  OPTION_SWITCH  to  a value  of  7 , he  would  specify 
it  as  follows:  .SET (0PTI0N_SWITCH=7) . The  left  hand  side  of  the 

"assignment  statement"  must  be  an  identifier  and  the  right  hand  side 
can  be  a numeric  value  or  a character  string. 

• .TEST  - Of  course  .SET  would  be  of  no  benefit  if  there  were  not  a 
means  to  test  the  variables  that  it  sets.  .TEST  provides  this 
capability.  .TEST  is  actually  a syntactic  element  that  sets  the 
parser’s  true-false  indicator  based  on  whether  the  specified  con- 
dition was  true  or  false.  That  is,  if  the  condition  specified  in 
.TEST  is  false,  it  will  have  the  same  effect  as  if  the  attempted 
recognition  of  an  element  had  failed. 


A-16 


.TEST  can  be  used  to  test  for  a not-equal  condition  as 

well  as  an  equal  ("=")  condition. 

2.3.4  Stack  Manipulation 

The  next  thiree  elements  are  used  primarily  to  accomplish  re- 
ordering of  the  output  items  (e.g.,  as  in  translation  from  infix 
operator  notation  to  suffix  notation) . To  facilitate  operations  of 
this  sort  the  generated  translator  is  provided  with  a push-down  stack. 
Output  items  or  groups  of  output  items  can  be  placed  on  the  stack  and 
saved  there  temporarily.  Later,  they  can  be  popped  from  the  stack 
for  output  or  simply  discarded. 

In  the  following  discussion  three  different  parameters  will 
appear  frequently.  Since  their  meaning  is  constant,  they  are  de- 
fined here  to  avoid  unnecessary  repetition. 

1)  # - the  pound  sign  always  refers  to  the  item  on  the  top 

of  the  translator  stack. 

2)  * - an  asterisk  always  refers  to  the  last  terminal  symbol 

recognized  in  the  parsing  process. 

3)  **  - double  asterisks  always  refer  to  the  variable  currently 

indicated  by  the  symbol  table  pointer. 

• ,SAV  - This  element  places  one  or  more  items  on  the  stack,  agying 

them  for  future  reference.  The  items  are  enclosed  in  parentheses 
and  may  be  any  one  of  the  following  types;  1)  *;  2)  3)  a SNIR; 

or  4)  a character  string. 

• .CAT  - This  element  places  items  on  the  stack  by  catenating  them  with 
the  item  currently  on  the  top  of  the  stack.  That  is , it  differs 
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from  .SAV  in  that  it  does  not  cause  the  stack  to  be  ’’pushed  down". 
This  makes  it  possible  to  add  one  or  more  items  to  the  item  on  top 
of  the  stack.  The  result  can  then  be  treated  as  a single  unit  that 
can  be  popped  off  the  stack  by  a single  translator  command.  .CAT 
operates  on  any  of  the  four  items  that  can  be  specified  with  ,SAV. 
.TOP  - The  pop  command  is  used  to  simply  throw  away  the  top  item 
on  the  stack.  Since  only  the  top  item  on  the  stack  can  be  accessed, 
.POP  is  always  used  with  a pound  sign,  i.e.  .POP(#). 

Output 

The  next  two  elements  provide  the  output  mechanism  for  the  gener* 
ated  translator. 

.OUT  - This  element  can  be  used  for  normal  output  from  the  trans- 
lator stack.  When  used  with  a pound  sign  it  removes  the  top  item 
from  the  stack  and  causes  it  to  be  written  out„ 

.OUT  is  the  primary  output  element  and  is  sufficiently  flexible 
to  handle  all  other  types  of  output  except  labels.  .OUT  is  followed 
by  a list  of  output  items  separated  by  commas  and  enclosed  in  paren- 
theses. An  output  item  may  be  any  of  the  following  five  types: 

1)#;  2)*;  3)**;  4) a SNIR:  or  $ a character  string  enclosed  in 
double  quotes.  The  last  of  these  types  is  the  most  common.  These 
character  stijings  will  usually  be  parts  of  program  statements  in 
the  object  language  of  the  generated  translator. 

.LAB  - This  element  allows  the  generated  translator  to  create  and 
output  statement  labels.  The  label  name  may  be  generated  from  a 
SNIR  or  from  the  last  recognized  terminal  symbol.  For  example,  if 


thfi  last  symbol  was  IABEL4,  .LAB(*)  would  result  in  the  output, 

, "1ABEL4:".  .LAB  simply  appends  a colon  to  the  appropriate 

character  string  and  then  outputs  it. 

2,3.6  Symbol  Table  Operations 

Since  the  generated  translator  must  collect  information  about 
the  identifiers  and  data  aggregates  encountered  in  the  source  pro- 
gram, it  is  provided  with  a "built-in"  symbol  table.  The  symbol 
table  is  an  essential  part  of  the  translator  and  is  used  for  storage 
of  symbol  names  and  attributes.  The  ten  elements  discussed  below 
can  be  employed  by  the  user  to  build,  interrogate,  and  modify  this 
table. 

In  order  to  allow  and  encourage  structured  programming  techniques, 
the  symbol  table  has  intentionally  been  designed  to  easily  accommo- 
date block  structured  languages.  It  consists  logically  of  a two- 
dimensional  table  and  a pointer  that  can  be  moved  to  any  table 
location.  Each  entry  in  the  table  consists  of  a symbol  name  and  a 
character  string  specifying  the  symbol  attributes.  Each  row  in  the 
table  corresponds  directly  to  a source  program  "block"  of  code. 

• . BLKENTER  and 

• .BLKEXIT  - These  two  elements  are  used  to  move  the  symbol  table 
pointer  vertically.  .BLKENTER  moves  the  pointer  down  a row  and 
effectively  clears  from  the  row  all  previous  symbol  entries  at  that 
level.  .BLKEXIT  simply  moves  the  pointer  up  a row.  These  elements 
can  be  used  to  implement  a stack  symbol  table.  Such  an  implemen- 
tation is  especially  useful  in  a one-paSs  translator  whose  source 
language  is  block  structured. 
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.SEARCH__BLOCK  and 

,SEARCH__ALL  - Before  a new  symbol  Is  entered  into  the  symbol  table 
it  is  almost  always  necessary  to  perform  a search  of  all  or  part  of 
the  table  in  order  to  insure  that  the  symbol  has  not  already  been 
entered.  These  two  elements  provide  both  the  search  and  entry 
functions,  . SE ARCH_BLOCK  searches  only  the  last  row  of  the  symbol 

table,  attempting  to  match  each  entry  with  last  terminal  symbol 
recognized  (normally  referenced  with  an  asterisk) , If  the  symbol 
is  not  found,  it  is  entered  as  the  next  symbol  in  that  row.  .SEARCH__ 
ALL  operates  in  the  same  way  except  that  it  searches  the  entire 
symbol  table  from  the  current  blocb  up.  Symbols  that  it  does  not 
find  are  entered  at  the  highest  level  (i.e,,  the  first  row). 

.IF  NEW  - This  element  is  often  used  immediately  after  ,SEARCH_ 

BLOCK  and  ,SEARCH_ALL.  It  is  the  primary  mechanism  by  which  symbol 
attributes  are  entered  in  the  symbol  table  and  associated  with  a 
given  symbol  name.  .IF__NEW  checks  to  see  if  the  symbol  currently 
indicated  by  the  pointer  is  a new  entry 5 if  so,  its  associated  attri~ 
bute  character  string  is  changed  to  user-supplied  specifications. 
Three  arguments  must  be  supplied.  The  first  two  are  integers  that 
specify  the  position  and  length  of  the  portion  of  the  attribute 
character  string  to  be  modified.  The  character  string  to  be  entered 
is  the  tb'‘rd  argument,  as  ,IF_NEW(1,2 ,"PD") > 

.ENTER  - The  usage  and  operation  of  .ENTER  are  the  same  as  those  of 
.IF__NEW  with  one  difference.  As  might  have  been  guessed,  .ENTER 
operates  unconditionally  (i.e,  the  attribute  entry  is  always  made. 


regardless  o£  whether  or  not  the  current  symbol  table  entry  is 
new , ) 

.TABIiEJTEST  An  attribute  character  string  is  specified  with  this 
element  in  the  same  way  as  with  ,IF_NEW  and  .ENTER.  .TABLEJTEST 
attempts  to  match  the  specified  string  with  the  -attributes  of  the  sym- 
bol currently  indicated  by  the  symbol  table  pointer.  It  then  sets 
the  translator^  true-false  indicator  based  on  the  success  or  fail- 
ure of  this  attempted  match.  This  element  is  syntactic, 

,INIT  BLOCK  - This  element  simply  moves  the  symbol  table  pointer 
to  the  beginning  of  the  latest  symbol  table  row,  which  contains  all 
the  symbols  encountered  thus  far  in  the  translation  of  the  current 
source  program  block. 

.FIND  NEXT  - This  element  is  used  to  find  the  next  symbol  table 
entry  in  the  current  row  that  has  a given  set  of  attributes.  It 
begins  its  search  with  the  symbol  after  the  one  indicated  by  the 
symbol  table  pointer.  If  a symbol  with  the  given  attributes  is 
found,  the  sjanbol  table  pointer  is  updated  to  indicate  the  approp- 
riate entry.  The  attribute  character  string  to  be  found  is  specified 
with  standard  three- argument  format. 

This  element  is  often  preceded  by  an  ,INIT__BLOGK  and  then  in- 
voked iteratively  to  find  all  symbols  of  a given  type  at  the  current 
block  level. 

. SE ARCHJPROCEDURE  - This  element  is  not  in  any  way  related  to  the 
symbol  table  but  is  functionally  similar  to  .SEARGH__BLOCK.  It 
searches  a separate  list  of  names  for  a character  string  specified 


inraiediately  after  it  and  enclosed  in  parenthesis.  If  a name  is 
‘ found  in  the  list  that  matches  the  specified  string,  its  associated 
count  is  incremented  by  one.  Otherwise,  the  new  name  is  entered 
into  the  list  and  its  count  is  initialized  to  one.  This  mechanism 
is  available  to  the  user  as  a general  tool  and  can  be  used  for  a 
variety  of  purposes  (e.g.  statistics  keeping,  data  area  from  which 
wrapup  code  can  be  generated,  etc.) 

2.3.7  Artificial  Control 

The  syntactic  and  semantic  elements  discussed  so  far  provide 
the  bulk  of  the  functional  capabilities  generally  required  by  a 
translator.  The  additional  elements  described  below  can  be  used 
to  furnish  some  degree  of  artifieal  control  over  the  parsing  pro- 
cess. This  makes  the  generated  translator  more  flexible  by  allow- 
ing some  variation  from  its  normal  top-down  deterministic  operation 
• .EMPTY  - This  element  is  equivalent  to  a reference  to  the  null 
character  string.  Of  course,  this  syntactic  element  is  always 
matched  during  the  parsing  process.  This  fact  makes  .EMPTY  useful 
for  forcing  the  top-down  deterministic  parser  to  commit  itself  to 
a given  grammar  rule. 

.EMPTY  is  also  useful  for  specifying  optional  elements.  For 
example,  one  could  define  a number  to  be  preceded  by  an  optional 
plus  or  minus  sign  with  the  following  rule: 

NUMBER;  = ("+"  | I .EMPTY)  .NUM; 

This  rule  specifies  that  either /'+•',  or  nothing  at  all  may 

precede  the  number  itself. 
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.NEG  - This  element  unconditionally  sets  the  parser’s  true-false 
Indicator  to  false.  Of  course  this  normally  occurs  only  when  there 
is  a failure  to  recognize  a syntactic  element. 

.RETURN  - This  element  causes  immediate  return  from  the  currently 
active  rule  to  the  rule  that  invoked  it,  with  no  change  to  the 
setting  of  the  true-false  indicator.  Positive  or  negative  returns 
may  be  caused  by  ".EMPTY  .RETURN"  or  ",NEG  .RETURN",  respectively. 
.PEEK  - This  element  allows  the  translator  to  look  ahead  at  the 
next  source  symbol  without  removing  it  from  the  input  string.  The 
string  to  be  "peeked"  for  follows  .PEEK  and  is  enclosed  in  paren- 
thesis. The  parser's  true-false  indicator  is  set  based  on  whether 
or  not  the  next  symbol  matches  this  string.  It  is  also  possible  to. 
peek  for  a terminal  symbol  class  and  to  peek  for  a list  of  items, 
as  .PEEK(";"  I .ID). 

.DO  - This  element  can  be  used  to  cause  the  immediate  execution  of 
a statement  written  in  the  host  language  of  the  translator.  The 
statement  must  appear  as  a character  string  enclosed  in  parentheses, 
immediately  following  the  .DO,  e.g.  .DO("THIS  IS  A TRANSLATOR 
STATEMENT;").  .DO  causes  the  statement  to  be  output  in-line  with 
the  code  of  the  generated  translator. 

Since  it  is  rarely  the  case  that  the  needed  translator  logic 
cannot  be  implemented  using  the  other  elements,  the  use  of  .DO 
generally  should  be  avoided,  if  possible.  However,  .DO  is  a useful 
tool  for  generating  extra  logic  unrelated  to  the  translation  process 
(e.g.  output  formatting,  statistics  keeping,  etc.). 


2,3.8  Error  Recovery  and  Messages 

A sophisticated  translator  should  be  able  to  detect  and  recover 

from  errors  in  the  source  program  it  is  parsing.  The  detection  of 
errors  allows  appropriate  messages  to  be  output  to  the  programmer. 
Recovery  from  errors  allows  the  translator  to  continue  parsing, 
thus  detecting  all,  or  at  least  most,  syntax  errors  in  one  pass. 

The  remaining  elements  provide  both  the  recovery  and  message  output 

mechanisms  required. 

• .ERR  - This  element  is  used  to  conditionally  output  error  messages 
and  also  provides  needed  error  recovery  capabilities.  The  error 
message  can  be  specified  directly  as  a character  string  or  indi- 
rectly by  an  integer.  If  an  integer  is  used,  it  is  assumed  to  be 
the  index  of  a message  contained  in  a user-supplied  array  called 
"0ERROR__MESSAGE" . 

The  two  elements  described  below  are  used  as  arguments  by  .ERR 
to  scan  past  extraneous  information  before  normal  operation  of  the 
parser  is  resumed, 

.SCANTO  - causes  the  translator  to  scan  to  the  first  occurrence 
of  the  character  string  specified  as  its  argument. 

.SCANBY  - causes  the  translator  to  scan  to  the  character  after 
the  first  occurrence  of  the  specified  character  string. 

The  argument  of  .SCANTO  or  .SCANBY  can  be  the  character  string  to  be 
scanned  for  or  it  can  be  ”MATCHING^PAREN*’ . The  latter  causes  the 
translator  to  find  the  next  unmatched  right  parenthesis. 

It  is  important  to  note  that  .ERR  takes  no  action  at  all  unless 
the  parser’s  true-false  indicator  has  a value  of  false.  This  makes 
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it  easy  to  place  .ERR  in-line  with  the  expected  syntactic  elements 
(e.g.  "END"  ,ERR("ERROR---MISSING  END  STATEMENT , .SCANTO(" ;"))  ). 

.MESSAGE  - This  element  is  similar  to  .ERR,  except  that  its  action 
is  unconditional  and  it  allows  no  scanning  options.  It  sets  the 
parser's  true-false  indicator  to  false. 


2.4  A Simple  Example 

To  aid  the  reader  to  become  familinr  with  this  method  of  com- 
bined  syntactic/semantic  specification,  a simple  arithmetic  assign- 
ment language  is  fully  defined  in  this  section,  and  the  definition  is 
applied  to  a brief  program  in  the  language.  It  is  perhaps  easiest 
to  consider  the  program  first,  since  it  provides  an  insight  into  the 
nature  of  the  language  to  be  defined.  The  program  reads  the  diameter 
of  a sphere  and  calculates  and  writes  the  sphere's  volume  by  a suffi- 
ciently roundabout  method  to  demonstrate  the  language  concept. 

PI  « 3.14159  » 

«EAD  DIAMETER  I 
RADIUS  * diameter  / ^ \ 

VOLUME  » 4 / 3 * PI  * RADIUS  * RADIUS  * RADIUS  » 

WRITE  volume  I 
END  » 

For  the  sake  of  simplicity,  no  branching  or  conditional  statements 
are  included.  Since  there  is  only  one  program  flow  in  which  all  state- 
ments are  executed  in  sequence,  the  "END"  statement  serves  double  duty 
as  a "STOP"  statement. 

This  section  will  illustrate  the  translation  of  this  language  into 
instructions  for  an  artificial  assembler-language-like  "pseudomachine", 
and  into  PL/ I. 

Consider  a simple  machine  capable  of  performing  functions  necessi- 
tated by  this  language.  The  machine  has  been  designed  for  conceptual 
simplicity.  It  does  not  actually  exist  in  the  simple  (but  inefficient) 
form  given  here,  and  it  will  therefore  be  referred  to  as  a pseudomachine. 
This  is  not  to  suggest  that  such  a machine  could  not  be  built;  it  is 


A-26 


not  difficult  to  build  a software  machine  (i.e.,  an  emulator)  with 
the  characteristics  specified  here.  The  11  operations  of  this  sim- 
ple machine  are  in  fact  a subset  of  the  operations  of  the  PLANS  pseudo 
machine,  for  which  we  have  built  such  an  emulator. 

The  most  basic  characteristic  of  the  pseudomachine  is  that,  in 
addition  to  ordinary  memory  for  randomly  accessible  storage  of  vari- 
able values,  it  has  a push-down  stack  (last-in-first-out  queue)  which 
serves  as  the  basic  storegs  medium  for  its  central  processor.  All 
data  operations,  including  in  particular  all  memory  access  and  update 
operations,  are  done  through  the  stack,  which  replaces  all  the  regis- 
ters (except  the  instruction  address  register)  of  a typical  simple 

computer.  . 

The  pseudomachine  is  a single-address  machine  that  is  programmed 

in  a language  very  similar  to  ordinary  assembler  languages.  For 
purposes  of  language  definition,  it  is  assumed  that  this  “symbolic 
language  is  the  actual  language  of  the  machine,  with  no  translation 
step  involved.  This  is  purely  a simplifying  assumption,  however, 
with  no  implications  for  the  use  of  the  pseudomachine  as  a semantic 
definition  tool  only. 

The  11  operations  which  can  be  performed  by  this  simple  pseudo- 
machine are  defined  in  Fig.  4. 

Consider  now  the  sequence  of  pseudomachine  commands, 

LDA  RADIUS 

LD  DIAMETER 

LDL  2 

DIV 

STO 
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!_CL  &PERANO  (LOAU  LITERAL) 

PUSH  THE  literal  OPERAND  ONTO  THE  STACK. 

fc.G.»  LDL  PATLOADS  RESULTS  IN  TML  TRANSFORMATION: 

XAKXXX  PaTLOADS 

tytyyy  -->  xxxxxx 

YYYYYY 

L’OA  QPERANO  (LOAD  ADDRESS) 

PUSH  THE  address  contained  IN  THE  OPERAND  FIELD  (I.E.,  THE 
address  corresponding  to  THE  TARIAOLE  name  In  THE  OPERAND) 

ONTO  THE  STACK. 

E.G.t  IF  THE  CORE  ADDRESS  OiADO  CORRESPONDS  TO  THE  VARIARLE 
NAME  •XVAR*.  then  LOA  XVAH  RESULTS  IN  THfc  TRANSFORMATION! 
XXXXXX  U1A30 

YYTYYY  XXXXXX 

YYYYYY 

LO  OPERAND  (LOAD) 

PUSH  THE  content  of  THE  ADDRESS  (I.E.t  VARIABLE  NAME)  IN  THE 
operand  field  onto  The  stack. 

E.6.»  IF  THE  content  OF  COHE  ADDRESS  0IA38.  REFERENCED  AHOVEt 
Is  -316.25*  THEN  LO  )<VAR  RESULTS  IN  THE  TRANSFORMATION! 
XXXXXX  -316. 2S 

YYYYYY  — > XXXXXX 

YYYYYY 

STO  (STORE) 

store  the  content  of  position  1 AT  THE  ADDRESS  CONTAINED  IN 
position  2.  POP  i POSITIONS. 

E.G.*  STO  results  IN  THE  TRANSFORMATION! 

2T*2  XXXXXX 

0IA30  -«•>  YYYYYY 

XXXXXX 
YYYYYY 

MHIlE  replacing  the  PREVIOUS  VALUE  OF  XVAR.  -316.25*  RT  27.2. 
(INPUT) 

READ  A NUMERICAL  VALUE  IN  STANDARD  EXTERNAL  FORMAT  FROM  a 

Punched  card,  place  the  value  in  the  address  in  position  i. 
POP  1 position. 

t.G.r  IF  VARIABLE  'X!  IS  LOCATED  AT  ADDRESS  130  AND  IF  ThE 
NEXT  PUNCHED  CARD  TO  BE  READ  CONTAINS  THE  STRING  22.7. 

Then  the  statement  in  results  in  the  stack  transformation! 

130  xxxxxx 

XXXXXX  — > YYYYYY 

YYYYYY 

•iHIlE  replacing  the  current  value  of  X by  the  NE«  value  22.7. 


rig.  4 Operations  of  a Simple  Pseudomachine 


OUT 


(OUTPUT) 

Print  the  numerical  value  contained  at  the  address  in  position  i. 
POP  1 position. 

E.G.*  IF  the  variable  'X*  is  located  at  address  130  and  has  the 
current  VALUE  22.7*  THEN  THE  STATEMENT  OUT  RESULTS  IN  ThE 
SlACK  TRANSFORMATION! 

130  XXXXXX 

XXXXXX  — > YYYYYY 

YYYYYY 

■mile  printing  The  numerical  value  22.7. 

ADO  (ADD) 

AOD  iHt  contents  of  positions  1 and  2.  replace  The  content 
OF  position  2 BY  THE  RESULT*  POP  1 POSITION. 

E.G.*  ADD  HESUlTS  in  THE  TRANSFORMATION! 

23  HV 

5 — > XXXXXX 

XXXXXX  YYYYYY 

YYYYYY 

SUB  (SUBTRACT) 

subtract  the  CONTENT  OF  POSITION  1 FROM  THAT  oF  POSITION  2* 

replacethe  content  of  position  2 BY  The  result*  pop  1 Position. 
E.G.*  sub  results  in  the  TRANSFORMATION! 

23  -IV 

b - — > XXXXXX 

XXXXXX  YYYYYY 

YYYYYY 

mult  (MULTIPLY) 

multiply  the  CONTENTS  OF  POSITIONS  1 AND  2*  REPLACE  THE  CONTENT 
OF  POSITION  2 BY  ThE  RESULT*  POP  I POSITION, 

E.S.*  MULT  ■ HESULTS  IN  ThE  TRANSFORMATION! 

12  36 

3 — > XXXXXX 

xxxxxx  YYYYYY 

YYYYYY 

OlV  (DIVIDE) 

DIVIDE  The  content  of  position  l into  the  content  of  position  2* 
replace  the  content  of  position  2 by  The  result*  pop  i position. 
E.G.*  OIV  results  in  the  transformation; 

12  .2S 

3 — > xxxxxx 

xxxxxx  YYYYYY 

YYYYYY 

STOP  (STOP)  . 

Slop. 


which  will  shortly  be  seen  to  correspond  to  the  statement 
RADIUS  = DIAMETER  / 2; 

Assuming  that  the  variable  names  ’RADIUS'  and  'DIAMETER'  correspond 
to  memory  locations  1012  and  1014,  respectively,  consider  the  effect 
of  executing  these  pseudomachine  commands. 

The  statement 
LDA  RADIUS 

pushes  the  address  1012  onto  the  (assumed  empty)  stack,  leaving  the 
stack  in  the  state 
1012 

The  statement 
LD  DIAMETER 

pushes  the  value  of  diameter  (say,  7)  onto  the  stack,  with  the  result 

7 

1012. 

The  statement 
LDL  2 

pushes  the  value  2 onto  the  stack,  yielding 

2 

7 

1012. 

The  statement 
DIV 

divides  7 by  2,  throws  away  those  numbers  (i.e.,  "pops"  them  off  the 
stack)  and  places  the  quotient  on  the  stack,  with  the  result 
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3.5 

1012. 


The  statement 
STO 

places  the  value  3.5  in  memory  location  1012  in  place  of  the  previous 
value  of  the  variable  'RADIUS' . 

Now  that  a pseudomachine  is  fully  defined,  the  final  step  in 
language  definition  is  the  specification  of  the  correspondence  be- 
tween the  source  language  and  the  speudomachine  commands.  For  the 
language  in  question,  the  language  definition  of  Fig.  5 is  appropriate. 

Using  this  augmented  grammar,  let  us  now  consider  the  parsing 
and  translation  of  the  sta.tement 
RADIUS  = DIAMETER  / 2; 

Fig.  6 shows  a parse  tree  for  this  statement.  In  addition,  the  object 
statements  (the  translator  output)  are  shown  encircled.  Just  as  the 
input  stream  was  parsed  left  to  right,  the  output  statements  were 
generated  left  to  right,  with  one  exception.  In  order  to  translate 
from  infix  binary  operator  notation  in  the  source  language  to  suffix 
notation  in  the  object  language,  it  was  necessary  to  save  (in  the 
grammar,  .SAV)  the  binary  operator  "DIV"  until  after  the  output  "LDL  2" 
had  been  generated,  and  then  to  place  the  saved  operator  in  the  out- 
put stream  (in  the  grammar,  .OUT (#)).  Since  this  was  accomplished 
with  two  instructions  that  were  evaluated  in  parse  order,  this  isn't 
really  an  exception  after  all. 
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•AUG^GHAM  ARITH 
ARITH  Ja 

$(  STATEMtNT  ”l»'  ) “tNO"  .OUT(STOP)  'M"  I 


STArEMtNT  1= 

• PEEK  (•'END”)  *NEG  *RETuRN 
I "HEAD”  .ID  .OUT(LDA.*/IN) 

I ”«*RITE”  .ID  .OUT(LDA.*/OUT) 

I^.ID  ,0UT(LDA.*)  EXPRESSION  .OUT(STO)  I 

EXPRESSION  := 

TERM  $<  ADD«0P  term  .oOT<#)  ) I 
TERM  Is 

FACTOR  S(  MUlT.OP  FACTOR  .OUT(#)  ) I 

factor  1= 

.NUM  .OUT(lDL*^*) 

I .ID  *0UT(LD**) 

I "{•»  expression  ”)"  ; 


ADD.OP  := 

.SaV(ADD) 

I .SAV(SUB)  I 


mult.op 

♦MUI 

I "/»* 


• 

,SAV(mULT) 
.SAV(DIV)  I 


.END 


Fig.  5 Complete  Definition  of  a Simple  Language 
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STATEMENT 


o 

I— 

t/) 

w 


The  reader  should  verify  that  the  given  language  definition  trans- 


lates our  original  sample  program 


PI  » 3,1^159  I 

Rf-AD  DIAMETER  I 

RADIOS'*  OTAMETtH/  2 I” 

VOLUME  ■ 4 / 3 • PI  • RADIUS  * RADIUS  • RADIUS  I 
KHITE  volume  • 

ENO'f 


into  the  pseudomachine  program, 


LOA 

PI 

LOL 

3*14159 

STO 

LOA 

DIAMETER 

IN 

LOA 

RAOtUS 

LO 

DIAMETER 

LOL 

2 

OIV 

STo 

LOA 

VOLUME 

LOL 

4 

LOL 

3 

OIV 

LO 

pr 

mult 

u6 

mult 

RAD1U$ 

LO 

RADIUS 

mult 

LO 

mult 

RADttJS^ 

sfo 

LM 

^OLUMe 

OUT 

sfop 

and  that  the  latter  correctly  expresses  the  original  program's 
function. 
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i 
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Now  let  us  consider  the  translation  of  the  original  program  into 
another  language  of  similar  level,  say  PL/I.  Because  the  source 
language  is  already  in  a PL/l-like  syntax,  this  translation  is  almost 
trivial.  As  an  exercise,  though,  it  should  provide  additional  in- 
sight. The  augmented  grammar  is  shown  in  Fig.  7. 


.Aue^bKAM  ARirn 

(haIN) I") 


STATEMtMT  I* 

.PEEK(”ENO'«)  .RETURN 

I ’'HEAD”  *10 

• OUT  1»»6ET.  EDIT  (”#  •♦).  (COL U ) #£(2^  * 0 ) ) I 

I *10 

*0Ur<»'PUT  SKIP  EDIT  (”#  *•)  (E  ( 1^**6)  ) I") 

! .10'  .X)-U-t(«) 

»*»•«  ,0UT(<») 

EAPHESSION  I 

EXPRESSION  l« 

term  S{  aod^op  term  ) » 

TERM  !■ 

FACTOR  S(  MULT.OP  FACTOR  ) I 


FACTOR  I* 


.NUM 

• OUT  <*) 

I .10 

.O.U[(*) 

! •'  ( " 

•out («) 

EXPRESSION 

.OUT(»> 

t 

aod,»op  »» 

ll<>M 

♦QUJ  > 

j Mali 

•0UT(«J 

1 

MUET^^OP 

•OUT {•) 

1 

.out (») 

1 

• END 


Flg»  7 Augmented  Grammar  for  ARITK-to-PL/l  Translation 


ARITH  IP 

• OUT  (»'DUMMVI  PROCEDURE  OPTIONS 

M statement  "»•»  .OUT(«|M)  ) 

"END”  “S” 

• OUT ("RE! URN  I" f "END  I")  I 
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3.0 


COMPONENTS  OF  THE  GENERATED  TRANSLATOR 


3.1  Lexical  Analyzer 

In  addition  to  the  automatically  generated  translator  and 
several  standard  support  routines  and  declarations  which  are  simply 
included,  as  is,  in  the  PL/I  translator  to  be  compiled,  several 
routines  and  declarations  require  user  inteiVention,  as  shown  in 
Figure  1.  The  first  of  these  is  the  lexical  analyzer,  which  recog- 
nizes the  basic  symbols  and  symbol  classes  (or  tokens)  of  the  source 
language . 

The  lexical  analyzer  consists  of  a subroutine,  usually  not  re- 
quiring modification,  and  a set  of  declarations  which  constitute  a 
table  by  which  the  subroutine  is  controlled.  This  section  discusses 
the  procedure  whereby  such  a table  is  constructed.  It  will  use,  as 
an  example,  an  early  TWS  lexical  analyzer. 

The  first  step  in  the  process  is  the  verbal  definition  of  the 
tokens  of  the  language.  For  our  example,  these  definitions  are  as 
follows. 

.ID  - Identifier.  One  to  31  characters,  all  alphanumeric  or 

underbar  (_) , first  character  strictly  alphabetic. 

.STRING  - Character  string  literal.  Logically  unlimited  in  length, 
first  and  last  characters  double  quotation  marks  (") • 

The  contained  characters  are  unrestricted,  except  that 
no  quotation  marks  may  occur  except  in  adjacent  pairs. 
.COMMENT  - Comment.  Unlimited  in  length,  first,  second  characters 
must  be  a slash  asterisk  (/*)  and  the  comment  must  be 
ended  by  an  asterisk  slash  (*/). 

A-36 


,SNIR  “ Symbolic  name  for  translator  generated  symbols.  Identi- 
fier followed  by  an  asterisk  (*) . 

.POINTSTR-  Point  string.  Period  (.)  followed  by  an  identifier. 

.NUM  - Number.  Includes  all  integer  digit  strings  only. 

In  addition  to  the  categories  mentioned,  the  following  are  single 
and  double  character  tokens: 


9 

0 

$ 

I 

# 

9 

/ 

* 

** 

The  next  step  in  the  process* is  to  convert  the  definition  to  a 
state  transition  diagram  which  defines  the  character-by-character 
scanning  process  to  be  performed  by  the  lexical  analyzer.  The  state 
transition  diagram  will  be  converted  to  a matrix,  and  it  is  certain- 
ly possible  to  skip  the  diagram  and  go  directly  to  the  matrix.  How- 
ever, fewer  errors  appear  to  result  if  the  recommended  approach  is 
used. 

Fig,  8 shows  the  state  transition  diagram  for  our  example.  The 
lexical  analyzer  always  starts  in  state  zero  (<1^).  One  state  trans- 
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ition  is  made  for  each  character  removed  from  the  input  string. 
Whenever  a purely  final  state  is  reached,  a complete  token  has  been 
scanned.  For  example,  is  a final  state  since  no  state  trans- 
itions from  are  indicated.  When  the  current  state  is  an  inter- 
mediate state,  another  character  must  be  scanned.  If  that  charac- 
ter causes  a legal  state  transition,  the  process  continues.  If 
not,  then  either  a token  has  been  processed  (if  the  current  state 
is  also  a possible  final  state)  or  an  error  has  occurred. 

Figure  9 shows  the  state  transition  matrix  which  corresponds 
to  Figure  8.  To  this  table  has  been  added  information  about  state 
types  and  information  identifying  the  special  terminal  symbol 
classes  (ID,  etc.).  Expressed  in  terms  of  the  matrix,  the  scanning 
algorithm  is  as  follows.  Starting  at  state  zero  or  row  zero  in  the 
table,  find  the  current  character.  From  row  zero  and  the  column 
corresponding  to  the  current  character  the  entry  defines  the  next 
row.  This  process  is  applied  until  no  transition  is  possible  to 
another  row.  If  the  state  type  corresponding  to  the  current  row  is 
final  a complete  token  has  been  parsed.  An  error  has  occurred  if 
no  transition  is  possible  and  the  corresponding  state  is  start  (S) 
or  intermediate  (I). 

1)  EXAMPLE;  ABC  = 

Starting  at  state  zero  with  the  letter  A and  the  raw,  column 
value  is  1.  Now  with  letter  B,  using  the  new  row  1 the  column 
corresponding  to  B contains  a 1.  Repeating  the  process  with  letter 
G,  using  row  1,  the  corresponding  column  also  points  to  1.  Finally 
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\CHAR 

state\^ 

1 

1 

1 

1 

1 

1 

1 

1 

■ 

0-9 

state 

type 

TOKEN 

type 

0 

■ 

11 

15 

15 

15 

14 

15 

15 

7 

15 

13 

15 

15 

H 

» 

Hi 

3 

s 

1 

2 

1 

■ 

■ 

B 

1 

IF 

ID 

2 

■ 

■ 

■ 

F 

SNR 

3 

■ 

■ 

3 

IF 

NUM 

4 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

5 

6 

6 

. 6 

I 

5 

6 

IF 

STR 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

— 

6 

6 

6 

6 

B 

6 

6 

I 

' 

7 

■ 

8 

B 

■ 

IF 

8 

■ 

8 

8 

8 

8 

9 

8 

8 

8 

8 

8 

8 

8 

8 

8 

B 

8 

8‘ 

I 

9 

■ 

8 

8 

8 

8 

9 

8 

8 

10 

8 

8 

8 

8 

8 

8 

8 

8 

8 

I 

10 

■ 

■ 

F 

CMT 

11 

■ 

■ 

■ 

■ 

H 

12 

I 

12 

■ 

12 

H 

12 

12 

IF 

13 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

15 

■ 

Hi 

I 

14 

15 

■ 

■ 

■ 

HI 

Hi 

Hi 

F 

15 

B 

■ 

■ 
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■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

B 

■ 

■1 

F 

STATE  TYPES 
S - START 
I - INTERMEDIATE 
F - FINAL 

Fig.  9 State  Transition  Matrix  for  Sample  Lexical  Analyzer 


when  the  character  (=)  is  looked  up  in  row  1,  no  transition  is 
possible. Since  row  1 is  a final  state,  the.  parse  is  complete.  The 
token  ABC  is  an  identifier  since  the  final  state  was  state/row  1, 

2)  EXAMPLE:  /*A*/ 

Starting  at  state  zero  with  a slash  (/)  the  row,  column  value 
is  7,  with  the  next  character  an  asterisk  (*) . Using  row  7,  the 
corresponding  column  value  is  8.  The  next  character  (A),  using  row 
8,  gives  a value  8.  Continuing  with  an  asterisk  (*)  and  row  8 
gives  a value  9.  Repeating  the  process  with  a slash  (/)  using  row 
9 the  corresponding  value  is  a 10.  Pinally,  when  the  character 
blank  is  looked  up  in  row  10  no  transition  is  possible.  Row  10  is 
a final  state,  so  the  parse  is  complete,  and  the  token  /*A*/  is  a 
comment  since  the  final  state  was  state/row  10. 

3.2  Output  Routines 

The  augmented  grammar  translator  output  package  for  PL/I  object 
code  consists  of  two  parts.  The  first  part  is  the  direct  output 
routine,  @0UT;  the  second  part  consists  of  the  routines  using  the 
code  stack. 

The  direct  output  routine  is  called  when  a reference  is  made  to 
the  augmented  grammar  element  .OUT.  The  direct  output  routine  @0UT 
has  a single  argument,  which  contains  the  next  portion  of  output  to 
be  written.  The  routine  @0UT  saves  the  code  in  a code  stack  until 
a complete  line  of  code  is  generated.  A line  of  code  is  output 
depending  on  the  following  conditions: 


‘ 1)  the  last  character  in  the  current  parameter  argument 

contains  a semicolon  (;).  This  causes  the  current  code 
saved  in  the  code  buffer  to  be  output,  starting  in 
column  5 . 

2)  the  last  character  in  the  current  parameter  argument  con- 
tains a cent  sign  (<:).  The  cent  sign  character  is  stripped 
off,  and  the  current  code  saved  in  the  code  buffer  is  out- 
put starting  in  column  5 . 

3)  the  last  character  in  the  current  parameter  argument  con- 
tains a question  mark  (?).  The  question  mark  is  stripped 
off  and  the  remainder  is  added  to  the  code  buffer. 

4)  the  last  character  in  the  current  parameter  argument  con- 
tains a colon  (:).  This  causes  the  current  code  saved 

in  the  code  buffer  to  be  output,  starting  in  column  2. 
(Labels  and  continuation  lines  start  in  column  2;  all 
other  lines  start  in  column  5 . ) 

5)  with  any  other  character  as  the  last  character,  the  para- 
meter argument  is  added  to  the  code  buffer  to  be  output  on 
a subsequent  call  to  @OUT . 

The  second  group  of  routines  allows  the  user  to  save  code  on  a 
stack  and  output  the  code  at  a later  time,  @OUT  may  be  used  in  the 
meantime  to  output  code  ahead  of  the  code  saved  by  these  routines. 
These  routines  are  written  as  a last-in-first-out  stack  and  are 
referenced  by  using  the  elements  ,SAV  and  .CAT  in  the  grammar.  The 
routines  are: 
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0SAV(arg)  - Calls  are  generated  by  a reference  to  element  .SAV; 

the  argument  is  added  to  the  top  of  the  stack  as  a 
separate  item. 

(aCAT(arg)  - Calls  are  generated  by  a reference  to  element  .CAT; 

the  argument  is  concatenated  to  the  top  item  of  the 
stack. 

Items  are  removed  from  the  stack  by  references  in  the  grammar  to 
.OUT(#).  This  generates  a call  to  @CODE__STK_OUT  which  in  turn 
references  @POP_CODE__STACK  finally  calling  @OUT  to  generate  the 

proper  output  files. 

% 

Ordinarily,  no  modification  of  these  routines  is  required  for 
PL/I  object  code  generation.  However,  certain  language  properties 
may  require  their  revision.  For  example,  in  the  translation  of 
PLANS  to  PL/I  it  was  necessary  to  be  able  to  output  statements  ahead 
of  the  statement  which  has  already  been  partially  output.  This  was 
accomplished  by  modifying  @OUT  so  that  it  contained  a stack  of 
partially  completed  lines  of  output.  Provision  was  made  for  adding 
' characters  to  the  current  incomplete  line,  outputting  the  current 
line,  pushing  a new  line  onto  the  stack,  and  popping  lines  off. 


3.3 


ERROR  MESSAGING 


For  simple,  nonproduction  languages,  the  user  may  simply  wish  to 
avail  himself  of  the  default  error  messaging  capability  of  the  TWS. 
Anytime  a required  syntactic  element  is  missing  in  a source  program 
and  no  .ERR  specification  immediately  follows  that  element  in  the 
augmented  grammar,  a system  error  message  will  result. 

If  the  user  desires  to  write  his  own  specialized  error  messages, 
he  may  do  so  in  either  of  two  ways.  The  error  message  may  be  written 
as  part  of  the  .ERR  specification,  as  .ERR ("S: MISSING  ARITHMETIC 
OPERATOR").  Alternatively,  the  user  may  provide  a declaration  of 
the  form 

DECLARE  (aERROR_MESSAGE  (5)  CHAR (60)  VARYING  STATIC  INIT( 

’N:THIS  IS  A NOTE ' , 

•W:THIS  IS  A WARNING' , 

'S:THIS  IS  A SEVERE  ERROR’, 

’F;THIS  IS  A FATAL  ERROR', 

’ S : MIS  SING  ARITHMETIC  OPERATOR ' ) ; 

With  this  declaration,  the  augiaented  grammar  element  .ERR (5)  would 
result  in  the  error  message  "MISSING  ARITHMETIC  OPERATOR"  any  time 
the  syntactic  element  preceding  the  .ERR  specification  is  not  found 
in  the  source  program. 

The  example  above  also  illustrates  all  four  error  message  sever- 
ity levels.  The  first  character  of  an  error  message  is  assumed  to 
indicate  the  severity  of  the  error.  The  symbols  used  are  "N" , "W" , 
"S",  and  "F",  for  note,  warning,  severe  error,  and  fatal  error, 
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respectively.  The  error  message  routine  automatically  sets  an 
appropriate  system  condition  code  for  the  most  severe  error  en- 
countered. In  addition,  a fatal  error  immediately  halts  the  trans 
lator,  while  a severe  error  terminates  code  generation,  but  allows 
continued  parsing  to  detect  any  other  errors. 


